"The Linux community is not a business, so no one can demand anything from it."
This strikes me as just ignorant, though he was too kind to put such a label on it. As he points out it is irrelevant that there is no "Linux 800 number"; business decisions by Fortune 500 companies used to having Compaq/Dell/Microsoft/IBM ready to make sure things work as advertised and desired.
"We don't want Linux used by the masses."
This is indeed unanswerable, and it saddens me that he actually got a response with this statement in it. You *better* want Linux to be used by the masses, because that's where the games/apps/hardware support is.
No, the VBRUN/COMCTL/CTL3D stuff is probably still there, but there are only 3-6 of these for ALL Windows software out there. Any Win9x system that's been running for more than a year tends to have these loaded on them somewhere.
This is an issue; however, I haven't scrummed my Windows system in about 2 years of downloading random shareware/freeware apps, and I never have to download any dependencies.
Nearly every time I want to download something new under Linux you have to deal with the "version number" dependency issue -- i.e., it works with a specific release number out to the third version number only.
'Tis true, I haven't had to upgrade a kernel for an install in a long time, but it did happen. Fun tho!
It's true it would be a 20meg package with all the DLLs it needs -- but what is 20megs of disk space these days?
And often it doesn't put the DLLs in the system directory at all but leaves them in the packages current directory.
The DLL/Library conflict issue is fundementally different from the installing issue; we shouldn't have to solve both of them at once.;-)
Personally, I like the package mentally in the Linux world. It just is conceptually *hard* to explain to somebody coming from the Windows world in the connect-download the one zipfile I need -disconnect world of networking.
YES debian does all those things, but all those things can commit you to a lot of time online when all you wanted was that 300k email package and find out you need 20megs of "dependencies" + compiling them all to get it too work.
This happens very rarely in the Windows world.
Believe me, I *love* the flexibilty and power dselect, rpm, gnorpm, kpackeg and such give me now that I have a cable modem connection. I hated it intensely when i had a 56k (sometimes) dialup connection.
Now you have to admit the uninstalling is less of a problem than it used to be.
And the absence of *dependencies* is huge. You can commit to downloading a 1meg file over a modem and not worry about then needing an additional kernel upgrade
... show off one of my linux systems to a Windows-literate friend. Not a complete newbie, but someone who is used to downloading shareware and freeware utilities for Windows. Invariably they ask what the equivalent of of self-extracting.exe file is.
Now you and I may be happy with a uuencoded shell script, or wading through the 31 flavors of rpms on rpmfind.net, but coming from the Windows it looks very alien. Thre is an undeniable niceness to grabbing a zipfile, unloading it into a temp directory, running the program for while, deciding whether to keep it, or to delete the directory.
No dependency-foo, no Gnu-make-foo, no glibc-foo. Just unpack it and go. No silly compile from scratch and hope you have the right kernel, libraries, compiler and support packages.
RPMs, DEBs, source distribution with autoconf all give the user a LOT of power and niceties. But it is still an order of magnitude more complex than InstallShield looks to the average user under Windows.
... is a babe! Still, it would be neato if the technology works. They seem to think it has a shot -- elsewise why offer to let 100k+ people follow it on the web?
I still think the roton is the coolest idea out there (www.rotaryrocket.com).
Re:Apocalypse Fixed, but the knowledge gap remains
on
Apocalypse Not
·
· Score: 1
I would agree the complexity of finding the problem cases was high, but the fixes themselves are note difficult.
Or, to put it another way, this was a problem that was hard only in the sense that massive amounts of resources were required. NOT hard because the solutions required creativity and "Eureka!" insight. So the problems were made much more solvable being throwing much more resources at them. In essence, this was more of a management challenge than a engineering challenge.
I absolutely agree that the geeks did an excellent job on this. But for a geek problem, this one was not very difficult. Only the scale made it hard. I would bet that most developers would not characterize the Y2K bug as the most chalenging techinical problem of their career, except in terms of how many hours they *had* to put in on it.
12 million lines of 1401 assembler? Ouch. But that is the result of successive bad decisions made for decades before Y2K was even an issue.
Apocalypse Fixed, but the knowledge gap remains...
on
Apocalypse Not
·
· Score: 4
So the media et al blew Y2K out of proportion? Of course they did, it was inevitable.
What was Y2K? An engineering problem. The only thing unique about Y2K as a engineering problem was the fact that you couldn't move the due date. In every other instance I can think of, you could to someone higher in authority and say "Hey look, we're not going to make it, can we push the end date out 1 month?" (or 1 year, 1 season, etc.). In this case there was no one to appeal to.
The combination of unslippable deadline and a lay person's lack of understand of how technology works combined to create undue worry over what was just another engineering problem.
And it wasn't a *hard* problem either. Not technically. Finding a fix for Y2K-imperiled code tended to be easy; scheduding and managing the upgrade of live systems with no disruption of service was in many cases hard. Coming up with the resources was hard for some companies. But the fixes themselves tended to be pretty obvious.
What really cracks me up is that developers routinely solve much harder problems with no such fanfare. Getting Windows to run at all with all that legacy software, now that took some brainpower (however misdirected). Compilers, major apps like MS/Star Office, and researchy-type apps typically face *hundreds* of more technically challenging hurdles during development.
The legacy of this will be that management/lay people will think there was nothing to Y2K and that IT folks just overstated the case. Not true. Furthermore they will extend this to trivialized daily jobs of software folks.
The core of this is the growing gap between the have's and have-not's in terms of technical understanding. Are we approaching the medical and legal professions for perceived disassociation from "average" citizens?
"Linux is a higher risk option than Windows NT. For example how many certified engineers are there for Linux?"
This is my favorite techie Ponzi scheme. All the various certifications you can get from M$, Novell, etc. are just a crock. They've turned into resume merit badges that dense managers use to justify hiring a particular person. "It's not my fault I hired John-the-idiot, he's an MCSE!". And now M$ uses it as an argument against Linux!
Of course the software companies are willing participants in this slush because they reap the money from the classes and testing for this nonsense. For Pete's sake, on the Powerbuilder certification test a few years ago they had questions on the location of menu items in the app! What does that have to do with anything!
There's no substitute for managers taking the time to ascertain if a person knows his/her stuff. Relying on silly certifications and such is just ostrich behavior. Very packer behavior;-) (for those who waded through The Programmer's Stone)
>Start creatng the impression that it is technically impossible to censor the Internet.
Seems to me,this will in all likelihood become true. Someone will embed crypto in IP packets, and you'll not be able to read the resulting datastream unless you have the key. Or one of a million other subtle ways. What about dual-use data? Sure it happens to be a porn picture if you process if as a GIF, but I am using the byte stream as a randomizer. That's what my clients use it for too? So sorry those bytes happen to align that way...
On the other hand, if authors are to self-regulate, the first time one of the authors labels his content in a way which disagrees with the "social experts" ("it's not porn, it's art"). then we go merrily skipping off to the Supreme Court.
Slashdot Mirror
Two of the replies he got stand out:
"The Linux community is not a business, so no one can demand anything from it."
This strikes me as just ignorant, though he was too kind to put such a label on it. As he points out it is irrelevant that there is no "Linux 800 number"; business decisions by Fortune 500 companies used to having Compaq/Dell/Microsoft/IBM ready to make sure things work as advertised and desired.
"We don't want Linux used by the masses."
This is indeed unanswerable, and it saddens me that he actually got a response with this statement in it. You *better* want Linux to be used by the masses, because that's where the games/apps/hardware support is.
Dependy-what? ;-)
No, the VBRUN/COMCTL/CTL3D stuff is probably still there, but there are only 3-6 of these for ALL Windows software out there. Any Win9x system that's been running for more than a year tends to have these loaded on them somewhere.
This is an issue; however, I haven't scrummed my Windows system in about 2 years of downloading random shareware/freeware apps, and I never have to download any dependencies.
Nearly every time I want to download something new under Linux you have to deal with the "version number" dependency issue -- i.e., it works with a specific release number out to the third version number only.
'Tis true, I haven't had to upgrade a kernel for an install in a long time, but it did happen. Fun tho!
It's true it would be a 20meg package with all the DLLs it needs -- but what is 20megs of disk space these days?
;-)
And often it doesn't put the DLLs in the system directory at all but leaves them in the packages current directory.
The DLL/Library conflict issue is fundementally different from the installing issue; we shouldn't have to solve both of them at once.
Personally, I like the package mentally in the Linux world. It just is conceptually *hard* to explain to somebody coming from the Windows world in the connect-download the one zipfile I need -disconnect world of networking.
YES debian does all those things, but all those things can commit you to a lot of time online when all you wanted was that 300k email package and find out you need 20megs of "dependencies" + compiling them all to get it too work.
This happens very rarely in the Windows world.
Believe me, I *love* the flexibilty and power dselect, rpm, gnorpm, kpackeg and such give me now that I have a cable modem connection. I hated it intensely when i had a 56k (sometimes) dialup connection.
Now you have to admit the uninstalling is less of a problem than it used to be.
And the absence of *dependencies* is huge. You can commit to downloading a 1meg file over a modem and not worry about then needing an additional kernel upgrade
... show off one of my linux systems to a Windows-literate friend. Not a complete newbie, but someone who is used to downloading shareware and freeware utilities for Windows. Invariably they ask what the equivalent of of self-extracting .exe file is.
Now you and I may be happy with a uuencoded shell script, or wading through the 31 flavors of rpms on rpmfind.net, but coming from the Windows it looks very alien. Thre is an undeniable niceness to grabbing a zipfile, unloading it into a temp directory, running the program for while, deciding whether to keep it, or to delete the directory.
No dependency-foo, no Gnu-make-foo, no glibc-foo. Just unpack it and go. No silly compile from scratch and hope you have the right kernel, libraries, compiler and support packages.
RPMs, DEBs, source distribution with autoconf all give the user a LOT of power and niceties. But it is still an order of magnitude more complex than InstallShield looks to the average user under Windows.
Just some thought for food,
... is a babe! Still, it would be neato if the technology works. They seem to think it has a shot -- elsewise why offer to let 100k+ people follow it on the web?
I still think the roton is the coolest idea out there (www.rotaryrocket.com).
I would agree the complexity of finding the problem cases was high, but the fixes themselves are note difficult.
Or, to put it another way, this was a problem that was hard only in the sense that massive amounts of resources were required. NOT hard because the solutions required creativity and "Eureka!" insight. So the problems were made much more solvable being throwing much more resources at them. In essence, this was more of a management challenge than a engineering challenge.
I absolutely agree that the geeks did an excellent job on this. But for a geek problem, this one was not very difficult. Only the scale made it hard. I would bet that most developers would not characterize the Y2K bug as the most chalenging techinical problem of their career, except in terms of how many hours they *had* to put in on it.
12 million lines of 1401 assembler? Ouch. But that is the result of successive bad decisions made for decades before Y2K was even an issue.
So the media et al blew Y2K out of proportion? Of course they did, it was inevitable.
What was Y2K? An engineering problem. The only thing unique about Y2K as a engineering problem was the fact that you couldn't move the due date. In every other instance I can think of, you could to someone higher in authority and say "Hey look, we're not going to make it, can we push the end date out 1 month?" (or 1 year, 1 season, etc.). In this case there was no one to appeal to.
The combination of unslippable deadline and a lay person's lack of understand of how technology works combined to create undue worry over what was just another engineering problem.
And it wasn't a *hard* problem either. Not technically. Finding a fix for Y2K-imperiled code tended to be easy; scheduding and managing the upgrade of live systems with no disruption of service was in many cases hard. Coming up with the resources was hard for some companies. But the fixes themselves tended to be pretty obvious.
What really cracks me up is that developers routinely solve much harder problems with no such fanfare. Getting Windows to run at all with all that legacy software, now that took some brainpower (however misdirected). Compilers, major apps like MS/Star Office, and researchy-type apps typically face *hundreds* of more technically challenging hurdles during development.
The legacy of this will be that management/lay people will think there was nothing to Y2K and that IT folks just overstated the case. Not true. Furthermore they will extend this to trivialized daily jobs of software folks.
The core of this is the growing gap between the have's and have-not's in terms of technical understanding. Are we approaching the medical and legal professions for perceived disassociation from "average" citizens?
"Linux is a higher risk option than Windows NT. For example how many certified engineers are there for Linux?"
;-) (for those who waded through The Programmer's Stone)
This is my favorite techie Ponzi scheme. All the various certifications you can get from M$, Novell, etc. are just a crock. They've turned into resume merit badges that dense managers use to justify hiring a particular person. "It's not my fault I hired John-the-idiot, he's an MCSE!". And now M$ uses it as an argument against Linux!
Of course the software companies are willing participants in this slush because they reap the money from the classes and testing for this nonsense. For Pete's sake, on the Powerbuilder certification test a few years ago they had questions on the location of menu items in the app! What does that have to do with anything!
There's no substitute for managers taking the time to ascertain if a person knows his/her stuff. Relying on silly certifications and such is just ostrich behavior. Very packer behavior
>Start creatng the impression that it is technically impossible to censor the Internet.
Seems to me,this will in all likelihood become true. Someone will embed crypto in IP packets, and you'll not be able to read the resulting datastream unless you have the key. Or one of a million other subtle ways. What about dual-use data? Sure it happens to be a porn picture if you process if as a GIF, but I am using the byte stream as a randomizer. That's what my clients use it for too? So sorry those bytes happen to align that way...
On the other hand, if authors are to self-regulate, the first time one of the authors labels his content in a way which disagrees with the "social experts" ("it's not porn, it's art"). then we go merrily skipping off to the Supreme Court.