libre hardware sounds good to me.
It sounds well but I don't really know the definitions out there and
the stablished usage of terms. Arguing about words is tricky,
specially without verily through understanding of their use.
Ethimology or synthetic meaning from name components only gets you so far.
Words mean what people take them to mean.
hmm ill have to ask others what hardware means to them.
Software is information on how to solve a problem with a computer,
hardware is the computer, wetware is the users who have the problem
(including developers).
For me anything hard to change is hardware, anything easy to change is
software. Hence the sensible FSF position on software on ROMs
being like hardware and software in EEPROMs being like software.
Then the question comes of hard _for whom_ to change. With signed blobs
there is software that is only soft for the vendor, not for the
users. With unsigned proprietary software the user may be able to
uninstall and replace it, but not do modifications, so it is softer
for the vendor than for the consumer. Free software is real soft for
everyone involved. Copyleft software is real soft for everyone
involved forever. Yet free software project governance can change a
little its stiffness and fragility. Hence that NASA engineer phrase
"if it ain't source, ain't software". I'd say "if it isn't source, it
isn't soft enough software".
Another question is _when_ something is software and when it is
hardware. In my view IP blocks start as software, maybe files written
in Verilog, VHDL or more modern languages, and gets passed around and
adapted. Then it is transformed to some other forms of software, and
in the fab it becomes hardware (no it doesn't, some copies of it are
made which are hardware, not exact copies, and the original software,
the hardware design remains, but the user often doesn't see it). Now
nobody can change it anymore (the hardware design can evolve into
different hardware, but the hardware copies can't be changed). Just
like catle is catle when it's alive and meat when killed, then you can
only eat it but you can't make it grow, milk it or breed and grow your
herd. So all farmers try to have some cattle breed before killing it.
Software becomes hardware when put in a ROM ? And in a CDROM ? It
depends. You can usually easily exchange a CDROM for another, you can
also copy it to RW media, and modify it. So your dead cow can be
resurrected. It's easier to just say the cow wasn't dead. Then there
are DRM and copy protection tricks that make life harder for your
veterinary. You may be able to change a socketed ROM but still need to
have one etched with the new software and that is not too easy if it
isn't an EEPROM.
That interpretation works for me, but I'm not aware of being official
or wildly supported. It's simplistic and can be in trouble with
details, but it's "good enough" defining. People get confused with
firmware, FPGAs, efuses, etc. Hardware developers have it more
difficult, because they don't look at things from the end of project
perspective, so they don't see it like users. They (mostly) think on
how to make hardware better when it still is software. So they tend to
forget it won't be hardware until they stop improving it. They modify
software but they are really thinking on the effects on the hardware
copies (in extreme cases they may even think on the distortions
introduced by the copy-to-hardware process). Just like farmers might
apply decisions to live cattle thinking on the taste or health effects
in the meat, and that does not make them cooks. And the copy of the
designs, which stays software, can breed and produce improved new
hardware revisions, which will again be software until they're done
and become hardware. Just like the farmer can selectively breed to get
better meat in future generations.
Last time I saw RMS at a conference he was asked about Libre hardware
(or similar, I don't remember the exact terms) and he answered more or
less that libre hardware doesn't exist, at least until we get some
photocopier for circuits, but libre hardware designs are very good
(but out of scope for him). More or less. I don't remember well. I
could look it up if it is recorded. The distiction is important but it
is understandably to just say libre hardware meaning "hardware which
comes with its libre hardware designs so the user can play farmer (or
hire farmers)".
And it seems some people are buying live cows. 78% of funds at 97% of
days, but 509 compute cards, 41 pass through cards, and 100 laptops
(assembled or kits). According to lkcl that makes into viable
territory for the laptop too... (although the criteria is not clear,
lkcl has already said it is better to leave the detailed analysis for
after the campaign, one of the early updates projected 500 cards and
140 laptops and thought it OKish, at some point he said if there were
500 cards it might do with just 100 laptops, and the last message there
concentrates on capital for travel, development and sustenance).
https://pyra-handheld.com/boards/threads/really-cool-modular-and-freedom-respecting-computer.77612/page-7
Btw. luke, this patch might "donate" 180$ to you ?
http://rhombus-tech.net/crowdsupply/assess_campaign.py
--- assess_campaign.py 2016-08-24 09:39:14.925861053 +0200
+++ assess_campaign4.py 2016-08-24 09:45:14.025302579 +0200
@@ -2,7 +2,7 @@
# PCB etc. extras (test, packaging, shipping)
sticker_cost = 4.0 + 3.0
-tshirt_cost = 20.0 + 5.0 # QTY 20 is $10
+tshirt_cost = 10.0 + 5.0 # QTY <20 is $20
cc_cost = 30.0 + 10.0
laptop_cost = 166.0 + 120.0
desktop_cost = 20.0 + 10.0
@@ -41,7 +41,7 @@
print "spare:", spare
print "nres: ", nres
print "after nres:", spare - nres
-cards = num_eoma68_a20s + num_breakouts
+cards = num_eoma68_a20s + num_passthroughs
sockets = num_desktops + num_laptops + num_breakouts
print "total MOQ cards", cards
print "total MOQ sockets", sockets
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-