Look it up on ltsp.org. I just got Suse+ltsp going (openmosix is next) and it was easier than I expected.
With a system supporting Preboot eXecution Environment:
computer powers on PXE looks for DHCP DHCP sends etherboot stub computer loads etherboot Etherboot looks for DHCP server DHCP sends linux kernel computer loads linux
kernel is configured and patched to do everything, including swap, from nfs share. local disk needed, just CPU and RAM.
While I understand how tiresome and boring it can be to have our morals, ethics, and beliefs get in the way of our more immediate gratification, that doesn't change the fact that Stallman has done more than anyone to get free and open software where it is today.
I don't know whether this is a misapprehension or a deliberate misconstrual, but let me state this clearly:
Prohibiting proprietary software is the ethically wrong, allowing developers to make their own choices about how to license their software is the ethically correct thing.
Programmer's have to deal with lots and lots and lots of undefined behavior. Language specifications contain undefined behavior, I know C++ does. APIs include lots of undefined behavior.
You can read "undefined behavior" as "may work fine in testing, but breaks in the real world." I've seen C++ undefined behavior that works fine in unoptimized builds, but crashes with the optimizer turned on. I've dealt with API calls that work fine under Windows 98 and crash in Windows 2000 (or was it the other way around).
Now a good programmer can make sure he doesn't do anything undefined if he's careful enough, but it sure makes the job harder. The amount of undefined behavior that software development involves makes it more like the medical profession than other engineering professions. Asking why computers still crash is like asking why, with modern medicine, people still get sick.
Of course, with new languages and new APIs, we may be able to escape this problem and make programming more like engineering.
I'd go further than that. This is like having a caching algorithm that determines what to keep in RAM based entirely on file size and whether the data is FS metadata. That seems unlikely to be the best way to use whatever RAM you have available for caching.
of course, the handwriting recognition is abysmal, but that goes without saying.....
Now I don't claim this was an extensive test, but I was blown away by the handwriting recognition. No, its not perfect, but I was writing some short phrases as fast as I could in cursive writing and having a hard time getting it to fail.
...but if my programming department is going to have to maintain a system, I don't want some unknown in a different department who thinks he's a slick Perl scripter (programmer, whatever) creating that system. I want somebody I know and trust to put the system together with tools that will likely result in a maintainable system.
Am I biased against Perl? Hell yeah. But only because I've used Perl. There are tools just as good for teeny tiny projects that won't collapse of their own weight if the grow to be any bigger. Some of them are scripting languages.
Am I willing to spend more hours of programmers I trust so I'm less likely to get bit in the ass by sloppy work later? Hell yeah again.
So am I biased against scripting? Hell no. But I will take actions that may look that way, especially to the Perl fanatic who doesn't get to play in the company's programming sandbox when I take away "his" project.
You gotta admit, even if our accomplishments aren't that great, programmer's arrogance is astounding. In another article on/.'s front page, nerds are unpopular because they're smarter than everybody else. And now...
Build a high-rise? Still pretty simple and straight forward
Puhleeease. Maybe the reason most software sucks isn't that our job is so much harder than everyone elses, but because we've got excuses for every damn thing that goes wrong.
Moore's so-called law is just a way of saying "Geez, this shit is changing really fast!" I'd say it applies less than it used to, but talk about it fitting (or not) "concrete observational data" is just plain absurd.
This idea that Save is good because we don't always want to keep what's saved has come up several times and it's wrong.
Remembering what we've done is what the the program should be doing all along. Occassionally, we want to tell the computer to forget some of what we've done, but "forget" is the command that the program should recognize. The fact that we need the "forget" command does nothing to make forcing a user to "save" any less crufty.
You might also look on ebay for Fujitsu Stylistic (pen tablet thingy) with a wireless card. Hang it on the wall mostly, carry it around now and then. In a pinch, you can even use it as a warming tray -- those little suckers run hot!
- Make it easy to find out about your toolset. If at all appropriate, make it easy to download and try out. Provide some good WORKING samples.
- Answer the phone/email. Developers won't call unless there's no other way to solve the problem. We know that phone and email support often sucks, but some times there's no other choice. At least respond.
- When we do need assistance, don't have support personnel treat us like complete idiots. Don't get me wrong, many of us are, but we all think we're geniuses and disabusing us of that notion is bad marketing.
Slashdot Mirror
Look it up on ltsp.org. I just got Suse+ltsp going (openmosix is next) and it was easier than I expected.
With a system supporting Preboot eXecution Environment:
computer powers on
PXE looks for DHCP
DHCP sends etherboot stub
computer loads etherboot
Etherboot looks for DHCP server
DHCP sends linux kernel
computer loads linux
kernel is configured and patched to do everything, including swap, from nfs share. local disk needed, just CPU and RAM.
Actually of that 70% the US owns, half belong personally to Al Gore.
I don't know whether this is a misapprehension or a deliberate misconstrual, but let me state this clearly:
Prohibiting proprietary software is the ethically wrong, allowing developers to make their own choices about how to license their software is the ethically correct thing.
Programmer's have to deal with lots and lots and lots of undefined behavior. Language specifications contain undefined behavior, I know C++ does. APIs include lots of undefined behavior.
You can read "undefined behavior" as "may work fine in testing, but breaks in the real world." I've seen C++ undefined behavior that works fine in unoptimized builds, but crashes with the optimizer turned on. I've dealt with API calls that work fine under Windows 98 and crash in Windows 2000 (or was it the other way around).
Now a good programmer can make sure he doesn't do anything undefined if he's careful enough, but it sure makes the job harder. The amount of undefined behavior that software development involves makes it more like the medical profession than other engineering professions. Asking why computers still crash is like asking why, with modern medicine, people still get sick.
Of course, with new languages and new APIs, we may be able to escape this problem and make programming more like engineering.
Well, if half of us are paying for sex, the other half are getting paid for it -- they're probably just not /. readers.
I'd go further than that. This is like having a caching algorithm that determines what to keep in RAM based entirely on file size and whether the data is FS metadata. That seems unlikely to be the best way to use whatever RAM you have available for caching.
Now I don't claim this was an extensive test, but I was blown away by the handwriting recognition. No, its not perfect, but I was writing some short phrases as fast as I could in cursive writing and having a hard time getting it to fail.
Why the hell would you want to do that with flash?
The problem I, and I suspect many others, have with Flash is that it excels most at doing things which just ought not to be done at all.
...but if my programming department is going to have to maintain a system, I don't want some unknown in a different department who thinks he's a slick Perl scripter (programmer, whatever) creating that system. I want somebody I know and trust to put the system together with tools that will likely result in a maintainable system.
Am I biased against Perl? Hell yeah. But only because I've used Perl. There are tools just as good for teeny tiny projects that won't collapse of their own weight if the grow to be any bigger. Some of them are scripting languages.
Am I willing to spend more hours of programmers I trust so I'm less likely to get bit in the ass by sloppy work later? Hell yeah again.
So am I biased against scripting? Hell no. But I will take actions that may look that way, especially to the Perl fanatic who doesn't get to play in the company's programming sandbox when I take away "his" project.
Sorry
Why stop at zero latency?
I want negative latency!
Moore's so-called law is just a way of saying "Geez, this shit is changing really fast!" I'd say it applies less than it used to, but talk about it fitting (or not) "concrete observational data" is just plain absurd.
Ummm, its not that hard in Outlook Express either
Tools->Options->Read tab
[x] Read all messages in plain text
Geez, how'd they make me say that?
but HTML and Perl have probably set us back 15-20 years.
This idea that Save is good because we don't always want to keep what's saved has come up several times and it's wrong.
Remembering what we've done is what the the program should be doing all along. Occassionally, we want to tell the computer to forget some of what we've done, but "forget" is the command that the program should recognize. The fact that we need the "forget" command does nothing to make forcing a user to "save" any less crufty.
You might also look on ebay for Fujitsu Stylistic (pen tablet thingy) with a wireless card. Hang it on the wall mostly, carry it around now and then. In a pinch, you can even use it as a warming tray -- those little suckers run hot!
Ok, read "advertising based" for free. You're quibbling about words, but the point is still agood one.
Suppose your a manager of some sort.
If you choose the lowest bidder and it doesn't work out, it's your fault.
If you choose the highest bidder and it doesn't work out, it's the contractor's fault.
And remember, it's not your money that your spending. It's budget money. And where do you, Mr. Manager, want to be at the end of the budget year?
Slightly over budget with good results. That way you get a bigger budget next year.
- Make it easy to find out about your toolset. If at all appropriate, make it easy to download and try out. Provide some good WORKING samples.
- Answer the phone/email. Developers won't call unless there's no other way to solve the problem. We know that phone and email support often sucks, but some times there's no other choice. At least respond.
- When we do need assistance, don't have support personnel treat us like complete idiots. Don't get me wrong, many of us are, but we all think we're geniuses and disabusing us of that notion is bad marketing.
Just ask your question and spare us the please-dont-flame-me-im-a-persecuted-christian attitude.
oops "It" = "Linux"
It sure as hell is if you've lost your product key...
I thought Satan already was a born again Christian.
I'm supposed to take design advice from someone putting up a scrolling two column web page??? Sheesh!