Pretty much, yes. It may work in the Chat activity.
It wasn't well thought out. It'd work great if the whole system were purely FORTH, Smalltalk, or LISP.
Consider the web browser. Does the key view the web page HTML, the Python wrapper around the firefox engine, the firefox engine, the Python interpreter...? Don't forget the C library, the X server, libjpeg, and the kernel!
Then, uh, you need tools. You need gcc, g++, bison, make, cvs, subversion, etc.
The issue is more general than that. The usability experts who can't code *can* improve usability, by telling the developers what to do.
In theory, yes. They can also fuck it up.:-)
Sugar (on the OLPC XO) is a great example. The screenshots are beautiful. The description sounds lovely. Actual day-to-day use is another matter entirely.
I doubt it was meant for a quiet environment. AFAIK, it was meant for a real live audience. People cough, chat, squeak their chairs...
I don't know where I'd get a quiet environment. Supposing I had one, I wouldn't want to just sit there waiting for the music to finish. Ugh. I have better things to do with my life.
In any case, that still wouldn't fix it. It still would have way to much of a difference.
It's possible that Mozart never intended to have such extremes. Modern recordings may be just bad because orchestras want to show off how much dynamic range they can manage, even at the expense of the music.
imagine going to see a classical music concert and the entire concert is played at the exact same volume, no crescendos or decrescendos
Sweet! Mozart might be tolerable, or even rather nice.
The number one thing I hate about typical classical music, particularly Mozart, is that I have to keep adjusting the volume knob while it plays. It's either deafening or inaudiable.
You get a new spam each time. A kid can create dozens or hundreds in a day, limited mainly by the general bad performance.
These entries have no reasonable use. They are clutter. Important stuff gets lost in the mess.
You're expected to regularly delete these I suppose. This is busy-work. It's difficult too, because you have to take care to avoid deleting something useful. It's additionally difficult because the journal's UI is both unintuitive and abysmally slow.
Sugar is god-awful slow. It's not even a real program; it's just a Python script.
Sugar has this thing called the journal. It "manages" your files with less sophistication than the 1984 Mac. There are no directories. It's all one big pile. It's full of spam even; every time you run a program you get a useless file in your journal.
Cisco for instance is making a push to use a FreeBSD derivate in all of its consumer products--displacing in some cases existing linux based hardware.
The people lose. They could have had control over their own hardware. They could have had the ability to share fixes that the vendor doesn't care to bother with. They could have had the ability to opt out of vendor-desired crap.
By solving that, you make the fueling problem worse.
Water alone is bad enough. It means walking into the gas station to buy an overpriced little bottle of spring water. If it is late at night, the store will be closed and you can't buy the water. At least begging for water is easier than begging for gasoline!
Adding alcohol makes it a special product. That might mean you buy a third item, a bottle of overpriced drygas fuel additive, and mix it into the water yourself.
People want to fill up with one thing, not two. Also, water freezes.
If people would tolerate that, we'd be using water with electrolysis to supply a tiny bit of hydrogen into a diesel engine. The hydrogen production and usage are both insignificant in terms of energy, but the diesel combustion behavior changes greatly when you add hydrogen.
The following activities are the favored ones. By that I mean that the OLPC people get all excited about them, think that they are ideal for all children, and want them on every laptop.
Tam Tam: it's supposed to be for music. You get 4 programs. One of them lets you click on icons for sound. It's just sound effects; you can not play a tune. Another program lets you mess with oscillators! There is an underperformaing program with pages of music on some kind of non-standard undocumented scale; the UI is painfully awkward though. You can choose from some awful instruments, like "dog" and "dice".
Pippy: this is Python. Eeeew, and ouch! You're limited to one file. You have to edit with the AbiWord (word processor) engine.
TurtleArt: this is a cross between LabView and Logo. It's hard to use, yet also very limited.
Etoys: no joke, this is Smalltalk!!! OMG, WTF??? It comes complete with tiny print and the, uh, "performance" you'd expect.
Plain old regular Linux runs fast too. Sugar is another matter entirely. It's a fucking overgrown script, and it even uses D-BUS (an RPC mechanism, also known as "D-COM for Linux") for that extra special slowness.
Sugar and Python are the Vista and.net of the Linux world.
Dual-boot will be developed to pacify some OLPC supporters. It will never ship.
Likewise, Sugar will be ported to Windows. It too will never ship. Nobody wants it: not the we-want-Windows government officials, not the free software fans, and certainly not Microsoft. Look at Java and JavaScript if you want to know how Microsoft feels about somebody slapping a portable API or ABI over top of the Microsoft-controlled ones.
Correct curly brace placement takes up less vertical space than incorrect brace placement.
(see K+R, or even Bjarne's crap -- when they agree, you know it's right)
we need it where it matters
on
The Return of Ada
·
· Score: 3, Interesting
All that vulnerable client-side code (image libraries, HTML parser, etc.) would be immune to buffer overflows if it were in Ada.
Even better, write it in proof-carrying Ada. (while an aritrary theorem prover is impossible, one can get a theorem prover to work in practice via minor tweaks to the input)
The cleaning crew is escorted by the watchman. The watchman has had a federal background check which included in-person interviews with friends and neighbors going back at least 7 years, probably 10 or more.
Slashdot Mirror
Multicast was in trouble before.
Now it has opposition with money.
The proprietary and expensive solution wins again. :-(
Pretty much, yes. It may work in the Chat activity.
It wasn't well thought out. It'd work great if
the whole system were purely FORTH, Smalltalk,
or LISP.
Consider the web browser. Does the key view the
web page HTML, the Python wrapper around the
firefox engine, the firefox engine, the Python
interpreter...? Don't forget the C library,
the X server, libjpeg, and the kernel!
Then, uh, you need tools. You need gcc, g++,
bison, make, cvs, subversion, etc.
The issue is more general than that. The usability experts who can't code *can* improve usability, by telling the developers what to do.
In theory, yes. They can also fuck it up. :-)
Sugar (on the OLPC XO) is a great example. The screenshots are beautiful. The description sounds lovely. Actual day-to-day use is another matter entirely.
Why else do you think they wrote Sugar in Python?
I actually think it is great to encourage the
eight year olds to patch software, but...
Since the problem is performance, and the solution
is getting rid of Python, all the damn Python isn't
helping at all!
I doubt it was meant for a quiet environment.
AFAIK, it was meant for a real live audience.
People cough, chat, squeak their chairs...
I don't know where I'd get a quiet environment.
Supposing I had one, I wouldn't want to just sit
there waiting for the music to finish. Ugh. I have
better things to do with my life.
In any case, that still wouldn't fix it. It still
would have way to much of a difference.
It's possible that Mozart never intended to have
such extremes. Modern recordings may be just bad
because orchestras want to show off how much
dynamic range they can manage, even at the
expense of the music.
imagine going to see a classical music concert and the entire concert is played at the exact same volume, no crescendos or decrescendos
Sweet! Mozart might be tolerable, or even rather nice.
The number one thing I hate about typical classical music, particularly Mozart, is that I have to keep adjusting the volume knob while it plays. It's either deafening or inaudiable.
Start some random activity. (terminal will do)
Having done nothing else, quit the activity.
You have spam!
You get a new spam each time. A kid can create dozens or hundreds in a day, limited mainly by the general bad performance.
These entries have no reasonable use. They are clutter. Important stuff gets lost in the mess.
You're expected to regularly delete these I suppose. This is busy-work. It's difficult too, because you have to take care to avoid deleting something useful. It's additionally difficult because the journal's UI is both unintuitive and abysmally slow.
Sugar is god-awful slow. It's not even a real program; it's just a Python script.
Sugar has this thing called the journal. It "manages" your files with less sophistication than the 1984 Mac. There are no directories. It's all one big pile. It's full of spam even; every time you run a program you get a useless file in your journal.
I can even think of two ways to block Linux.
If you can too, SHUT UP ABOUT IT!
Commodity hardware would suck, and you know it.
I want the selfish bastards to write their own OS.
The cost would put them at a (minor) disadvantage.
I want the competitors to win.
The no-MMU patches were accepted a long time ago. I think it's been years already. Linux supports several different architectures that lack an MMU.
Cisco for instance is making a push to use a FreeBSD derivate in all of its consumer products--displacing in some cases existing linux based hardware.
The people lose. They could have had control over their own hardware. They could have had the ability to share fixes that the vendor doesn't care to bother with. They could have had the ability to opt out of vendor-desired crap.
Gee, thanks BSD crowd... :-(
By solving that, you make the fueling problem worse.
Water alone is bad enough. It means walking into
the gas station to buy an overpriced little bottle
of spring water. If it is late at night, the store
will be closed and you can't buy the water. At
least begging for water is easier than begging
for gasoline!
Adding alcohol makes it a special product. That
might mean you buy a third item, a bottle of
overpriced drygas fuel additive, and mix it into
the water yourself.
NOT WORKABLE
You forgot good old hot fusion.
People want to fill up with one thing, not two. Also, water freezes.
If people would tolerate that, we'd be using water with electrolysis to supply a tiny bit of hydrogen into a diesel engine. The hydrogen production and usage are both insignificant in terms of energy, but the diesel combustion behavior changes greatly when you add hydrogen.
The following activities are the favored ones. By that I mean that the OLPC people get all excited about them, think that they are ideal for all children, and want them on every laptop.
Tam Tam: it's supposed to be for music. You get 4 programs. One of them lets you click on icons for sound. It's just sound effects; you can not play a tune. Another program lets you mess with oscillators! There is an underperformaing program with pages of music on some kind of non-standard undocumented scale; the UI is painfully awkward though. You can choose from some awful instruments, like "dog" and "dice".
Pippy: this is Python. Eeeew, and ouch! You're limited to one file. You have to edit with the AbiWord (word processor) engine.
TurtleArt: this is a cross between LabView and Logo. It's hard to use, yet also very limited.
Etoys: no joke, this is Smalltalk!!! OMG, WTF??? It comes complete with tiny print and the, uh, "performance" you'd expect.
People need to communicate. There is no place to
draw a line, cutting off more-vital parts from the
less-vital parts.
There mechanical protection systems, so you won't
be making meltdowns over the net.
Plain old regular Linux runs fast too. Sugar is another matter entirely. It's a fucking overgrown script, and it even uses D-BUS (an RPC mechanism, also known as "D-COM for Linux") for that extra special slowness.
.net of the Linux world.
Sugar and Python are the Vista and
Folks, this guy is +42 Extra Super Insightful.
Dual-boot will be developed to pacify some OLPC supporters. It will never ship.
Likewise, Sugar will be ported to Windows. It too will never ship. Nobody wants it: not the we-want-Windows government officials, not the free software fans, and certainly not Microsoft. Look at Java and JavaScript if you want to know how Microsoft feels about somebody slapping a portable API or ABI over top of the Microsoft-controlled ones.
Cloned meat will taste like corn, because that is
what will be used to produce it.
Correct curly brace placement takes up less vertical space than incorrect brace placement.
(see K+R, or even Bjarne's crap -- when they agree, you know it's right)
All that vulnerable client-side code (image libraries, HTML parser, etc.) would be immune to buffer overflows if it were in Ada.
Even better, write it in proof-carrying Ada. (while an aritrary theorem prover is impossible, one can get a theorem prover to work in practice via minor tweaks to the input)
The cleaning crew is escorted by the watchman. The watchman has had a federal background check which included in-person interviews with friends and neighbors going back at least 7 years, probably 10 or more.
It adds complexity, which is generally bad for security, and makes the format harder to understand, which is also bad.
The word that comes to mind is "dumbass".
I do hope there is an option to have an "ask the user" password. (not stored in file)
Eat your vegetables. Seriously.