Ten years after that we'll all just have chips (although they won't be called that) embedded in our brains
"Crisps"?
Re:Great for a real city (NY) Lousy for post WW2 c
on
This is IT?
·
· Score: 1
New York would be great for these things. My main concern is whether it's remotely possible to take one on a subway train without seriously inconveniencing everyone else (not that New Yorkers are typically bothered by the idea of inconveniencing others). There are a few blind spots in the subway system which would become a lot more accessible if you could cover the ground between stations at 10 mph.
I've always like the idea of restricting cars and bicycles to the major avenues and providing adequate parking facilities at the outskirts of the densely occupied areas. Keeping them away from pedestrians would probably make both sides happier. Something like the Ginger would let you space things out further, assuming that it can mix with foot traffic better than a bicycle or scooter.
I've had to do quite a bit of work with IPv6 at my job, and I have to say that it is not nearly as simple as flicking a switch. Support is growing, but most implementations just aren't that mature (I'm working with FreeBSD/KAME, which is getting into decent shape). Aside from addressing, most of the other nifty features of IPv6 (IPsec, autoconfiguration, etc.) have already been backported to IPv4. And most organizations have gotten used to NAT as the way of the world, so the addressing problem keeps getting pushed farther off into the future.
That said, the main thing standing in the way of IPv6 adoption is that nobody knows anything about it. There's minimal incentive for most network admins to learn about it these days, and it's not going to catch on until a critical mass of users know what's going on. It's amazing to watch the eyes of technically advanced people glaze over when I give a presentation on my (really quite basic) IPv6 work.
Of course, that's the view from the US. From what I hear, Asia and the wireless world have a lot more to gain from adopting IPv6 addressing in the near future. So maybe the traditional networking world will be behind the curve on this one.
IPv6, coming to your neck of the woods around the same time as cost-efficient nuclear fusion.
Buffy's much more character and dialogue-driven than plot-driven. Something that seems not to sit well with technical types. Most of the hardcore fans I know are liberal arts people in their late twenties.
In the end its all a matter of taste. Compare it with Babylon 5, which had far superior plotting but seriously inferior dialogue and acting. Getting all of the elements into top shape is nearly impossible, because nobody's interested in all of them at once.
One big assumption you're making is that everyone is desperately trying to move up the management ladder. My last job was at a tech company full of aggressive, upwardly-mobile people. Certainly there were ambitious people with management aspirations, but many didn't want any part of the responsibility that comes with a promotion.
I was initially promoted ahead of my peers, and they were happy to let me call the shots. Later, one of my fellow managers got promoted above me. I had no problem with this because he was better qualified to do the job. Especially with technical people, I find that it's often difficult to get subordinates excited about climbing the ladder. And it's a lot harder to move up in rank yourself if nobody wants to fill the void.
Finally, more than half of my close friends are former coworkers. I admit that it's easier to know if they're long-term friends after you stop working together, but my social life over the past four years would have been rather sparse if I didn't hang out with coworkers. Not only do they make the workplace much more pleasant, but the networking has helped move my career along quite nicely.
I'm planning to start doing the nfs-export thing for kernel installs, but only for initial system installation. Many of the boxes I'm concerned with will be isolated behind remote firewalls and low-bandwidth connections. Small binary packages are the most convenient way to keep them updated.
The main reason we're using BSD is that my management mandated it, but as I've become more familiar with the system I've come to appreciate some of its advantages. Mind you, I do think that the building-from-CVS thing is very valuable for developers. I just think that compilation and distribution need to be separated more cleanly.
I'm aware that there's a group working on a system for binary updates of the core OS, so it's not like these concerns have been ignored. In the meantime I'll probably resort to a homegrown toolset.
Having spent the last 6 months managing FreeBSD machines, I have mixed feelings about the whole cvsup/Ports concept. They're excellent for keeping a developer workstation in sync with updates. So far they've been horrible for homogenizing multiple production machines. I've been doing okay with Ports by using "make package" on a master machine (though upgrading packages has been hit-or-miss), but there's no equivalent mechanism for the core OS.
As a sysadmin, I'd really rather have official binary packages for most OS updates. And while I understand the reasoning behind the separation of the base OS from the add-on packages, it has proven to be very inconvenient in the field.
Using Unix IMAP clients with Exchange has been a good solution for me in the past, but you lose the mail/calendaring integration that is probably Exchange's strongest point. And shared calendaring is a lot less valuable when you don't have your entire department using it.
His point is that the things you (and I, mostly) find intuitive in a user interface are not intuitive to 95% of the people who use desktop computers. For instance, they don't care whether the configuration is stored in a binary registry or a human-readable text file because they're never going to edit either by hand. MS GUI config dialogs can often be confusing (especially in Office), but that's usually because they offer too much flexibility.
Maybe that means most of the people out there are already brainwashed. It doesn't really matter, because they're not going to suddenly start thinking like kernel hackers because we think they should.
I see that there's a section on developing on OpenAL. That seems like the way to go, but I was wondering if that whole initiative is dead in the water. There has been no news on that front for quite some time. Now that my graphical capabilities are up to snuff (thanks, Nvidia), I'm really starting to miss 3D sound.
I think the "toys" in question aren't Palm Pilots or even spiffy laptops. They're the Cisco multilayer switches, E10K servers and Symmetrix storage units that were flying off the shelves over the past few years. I have to admit that I really enjoy being able to work with high end equipment, but during the funding frenzy of the late '90s a lot of companies bought a lot of expensive hardware that they didn't really need. Their IT departments got blank checks to buy what they felt was necessary, and the only people in a position to question the purchases were too busy salivating over the next batch of gadgets on the way.
I've seen a few (small) companies throw millions of dollars into hardware upgrades when it was really their code and database designs that were slowing things down. Hopefully, now that the money is much harder to come by, people will have to focus more on building efficient systems instead of bigger ones.
Rugby's cool, but have you seen the sorts of injuries that American football produces? All that padding just encourages players to throw their huge bodies around harder. In sports without helmets, participants tend to have the common sense to not use their heads as battering rams.
I think this guy has it right, as far as what needs to happen in the next phase of kernel development. The problem is that these needs have arisen because the methods in question were rejected in the past. I'm reminded of my sophomore year in college, when I learned that native intelligence wasn't going to cut it anymore, and that maybe studying would be a good idea. Linux development seems to be at a similar point, where an individual's ability to manage things at a fine level becomes insufficient.
I don't enjoy doing project management myself, but I've definitely learned the value of having a PM on hand to help keep track of who's supposed to be doing what during a given period of time. The result is a better end-product, and that's supposed to be one of the benefits of open source development.
Then there's that whole spat over debuggers, specs and regression testing. That one seems to have devolved into an argument over whether the sun rises in the east.
"Disk" is short for "diskette". I don't recall anyone ever using the full term even back when it was new. If we're talking about a round flat thing, that's still spelled "disc" in the US. As in "compact disc".
I'd say that Novell as a standalone company has nothing to gain from open-sourcing NDS. They have a hard enough time making money as it is. As a part of IBM, however, they could very well do it. NDS would be a great integration tool for the many platforms and applications that IBM supports.
Linux, of course, would gain quite a bit from an open-source NDS.
There's a big difference between general learning in elementary school and getting work done in the real world. Challenges are good for learning, but tend to get in the way of actual productivity.
If your goal is to become intimately familiar with the operating system, then skipping the GUI and editing everything by hand is a good idea. If your goal is to write a couple of letters and play Quake, then it's a waste of time.
Just because you've chosen to specialize in a particular field, don't assume that it's best for everyone to follow the same path. I'd prefer that my doctors (for example) spend their time learning the fine details of medicine instead of writing shell scripts.
I disagree. Recruiting kernel hackers and Slashdot posters would net them some technical talent, but Linuxcare already has an abundance of that. What they're lacking is skilled managers and business leaders who could harness that talent and do something productive with it. Needless to say, those leaders would need to grasp the open-source concept and work well with the technical staff. But they wouldn't need to be (and probably shouldn't be) master-hackers in their own right.
Damn, I loved that game. Except I played it in CGA on a 4.77MHz IBM PC. It took about three seconds to move one step forward and five minutes to save the game. It was worth it, though.
Focusing on a single distribution makes QA and support a lot easier for them, and Red Hat on Intel gets them the bulk of the existing Linux installs (I figure Mandrake is close enough to be included).
This is an unfortunate side effect of the differentiation amongst distributions. The software will probably run fine on (for example) Debian/x86, but the cost of testing and supporting such a configuration far outweighs the potential revenue for an ISV. I'm hoping that the LSB will eventually smooth out these differences so that vendors can easily produce software that will run out of the box on any compliant distribution. That doesn't help alternate architectures, but at least it would put Linux on equal footing with Windows.
One thing about Linux that is a minor annoyance to me but a huge problem for the typical home user is the way device drivers are updated. If I install a random new peripheral under Win 98, the system detects the added hardware and asks for a driver disk. Since the disk generally comes with the peripheral, it's pretty easy for anyone to handle the install.
On the Linux side, I would typically have to upgrade my kernel to a version with support for that device. Or I would have to apply a patch to my kernel and recompile. These tasks are a lot easier now than in the old days, but they can be intimidating to new users and still present plenty of opportunity to screw up one's system.
I recall that there was some discussion among kernel developers about stabilizing a binary driver interface so that a precompiled driver module would work reliably with different kernel revisions. The argument which shot the idea down was that it would saddle the kernel with backwards compatibility issues and would encourage the development of binary-only drivers. I agree that these are both bad things, but I still feel that there needs to be some middle ground.
My initial thought here is that there should be a binary driver interface standard that evolves separately from the kernel proper. It's okay for it to change from time to time, but for the stable kernels there should probably be at least six months between revisions. Then perhaps we could establish a driver packaging format in which each package would include precompiled binary modules for multiple platforms (CPUs, SMP, etc.) and multiple versions of the driver interface standard. It could also include the driver source, so that the module could be compiled on the fly.
Obviously I've avoided most of the implementation issues here, but I would hope that this solution would make peripheral installation as easy for Linux users as it is for Windows users. It would also allow driver developers to work more independently of ongoing kernel development.
Your last point is the key. No matter how many user-friendly additions get incorporated into the mass-market Linux distributions, nothing is stopping the hardcore hackers from running Slackware and using vi as an all-purpose admin tool.
Some of these people remind me of MS advocates defending the company's right to control all computing. After all, if Windows, IE, Office, Bookshelf and the Sidewinder joystick aren't inextricably tied together, their freedom to avoid non-MS products is being threatened.
The people doing most of the flaming are not the ones who are doing the work of developing Linux. The latter group (including Linus himself) tends to be supportive of the sort of userspace developments that will be needed for Linux to achieve any kind of mainstream status.
Slashdot Mirror
Ten years after that we'll all just have chips (although they won't be called that) embedded in our brains "Crisps"?
New York would be great for these things. My main concern is whether it's remotely possible to take one on a subway train without seriously inconveniencing everyone else (not that New Yorkers are typically bothered by the idea of inconveniencing others). There are a few blind spots in the subway system which would become a lot more accessible if you could cover the ground between stations at 10 mph.
I've always like the idea of restricting cars and bicycles to the major avenues and providing adequate parking facilities at the outskirts of the densely occupied areas. Keeping them away from pedestrians would probably make both sides happier. Something like the Ginger would let you space things out further, assuming that it can mix with foot traffic better than a bicycle or scooter.
I've had to do quite a bit of work with IPv6 at my job, and I have to say that it is not nearly as simple as flicking a switch. Support is growing, but most implementations just aren't that mature (I'm working with FreeBSD/KAME, which is getting into decent shape). Aside from addressing, most of the other nifty features of IPv6 (IPsec, autoconfiguration, etc.) have already been backported to IPv4. And most organizations have gotten used to NAT as the way of the world, so the addressing problem keeps getting pushed farther off into the future.
That said, the main thing standing in the way of IPv6 adoption is that nobody knows anything about it. There's minimal incentive for most network admins to learn about it these days, and it's not going to catch on until a critical mass of users know what's going on. It's amazing to watch the eyes of technically advanced people glaze over when I give a presentation on my (really quite basic) IPv6 work.
Of course, that's the view from the US. From what I hear, Asia and the wireless world have a lot more to gain from adopting IPv6 addressing in the near future. So maybe the traditional networking world will be behind the curve on this one.
IPv6, coming to your neck of the woods around the same time as cost-efficient nuclear fusion.
Buffy's much more character and dialogue-driven than plot-driven. Something that seems not to sit well with technical types. Most of the hardcore fans I know are liberal arts people in their late twenties.
In the end its all a matter of taste. Compare it with Babylon 5, which had far superior plotting but seriously inferior dialogue and acting. Getting all of the elements into top shape is nearly impossible, because nobody's interested in all of them at once.
One big assumption you're making is that everyone is desperately trying to move up the management ladder. My last job was at a tech company full of aggressive, upwardly-mobile people. Certainly there were ambitious people with management aspirations, but many didn't want any part of the responsibility that comes with a promotion.
I was initially promoted ahead of my peers, and they were happy to let me call the shots. Later, one of my fellow managers got promoted above me. I had no problem with this because he was better qualified to do the job. Especially with technical people, I find that it's often difficult to get subordinates excited about climbing the ladder. And it's a lot harder to move up in rank yourself if nobody wants to fill the void.
Finally, more than half of my close friends are former coworkers. I admit that it's easier to know if they're long-term friends after you stop working together, but my social life over the past four years would have been rather sparse if I didn't hang out with coworkers. Not only do they make the workplace much more pleasant, but the networking has helped move my career along quite nicely.
I'm planning to start doing the nfs-export thing for kernel installs, but only for initial system installation. Many of the boxes I'm concerned with will be isolated behind remote firewalls and low-bandwidth connections. Small binary packages are the most convenient way to keep them updated.
The main reason we're using BSD is that my management mandated it, but as I've become more familiar with the system I've come to appreciate some of its advantages. Mind you, I do think that the building-from-CVS thing is very valuable for developers. I just think that compilation and distribution need to be separated more cleanly.
I'm aware that there's a group working on a system for binary updates of the core OS, so it's not like these concerns have been ignored. In the meantime I'll probably resort to a homegrown toolset.
Having spent the last 6 months managing FreeBSD machines, I have mixed feelings about the whole cvsup/Ports concept. They're excellent for keeping a developer workstation in sync with updates. So far they've been horrible for homogenizing multiple production machines. I've been doing okay with Ports by using "make package" on a master machine (though upgrading packages has been hit-or-miss), but there's no equivalent mechanism for the core OS.
As a sysadmin, I'd really rather have official binary packages for most OS updates. And while I understand the reasoning behind the separation of the base OS from the add-on packages, it has proven to be very inconvenient in the field.
It would appear, then, that there are no good or evil people in the world.
Using Unix IMAP clients with Exchange has been a good solution for me in the past, but you lose the mail/calendaring integration that is probably Exchange's strongest point. And shared calendaring is a lot less valuable when you don't have your entire department using it.
The consumer not only has to have a choice, he has to understand the choice. Scott Adams raised the notion of "confusopoly" with the telcos in mind.
Maybe that means most of the people out there are already brainwashed. It doesn't really matter, because they're not going to suddenly start thinking like kernel hackers because we think they should.
I see that there's a section on developing on OpenAL. That seems like the way to go, but I was wondering if that whole initiative is dead in the water. There has been no news on that front for quite some time. Now that my graphical capabilities are up to snuff (thanks, Nvidia), I'm really starting to miss 3D sound.
I've seen a few (small) companies throw millions of dollars into hardware upgrades when it was really their code and database designs that were slowing things down. Hopefully, now that the money is much harder to come by, people will have to focus more on building efficient systems instead of bigger ones.
Rugby's cool, but have you seen the sorts of injuries that American football produces? All that padding just encourages players to throw their huge bodies around harder. In sports without helmets, participants tend to have the common sense to not use their heads as battering rams.
I think this guy has it right, as far as what needs to happen in the next phase of kernel development. The problem is that these needs have arisen because the methods in question were rejected in the past. I'm reminded of my sophomore year in college, when I learned that native intelligence wasn't going to cut it anymore, and that maybe studying would be a good idea. Linux development seems to be at a similar point, where an individual's ability to manage things at a fine level becomes insufficient.
I don't enjoy doing project management myself, but I've definitely learned the value of having a PM on hand to help keep track of who's supposed to be doing what during a given period of time. The result is a better end-product, and that's supposed to be one of the benefits of open source development.
Then there's that whole spat over debuggers, specs and regression testing. That one seems to have devolved into an argument over whether the sun rises in the east.
"Disk" is short for "diskette". I don't recall anyone ever using the full term even back when it was new. If we're talking about a round flat thing, that's still spelled "disc" in the US. As in "compact disc".
I'd say that Novell as a standalone company has nothing to gain from open-sourcing NDS. They have a hard enough time making money as it is. As a part of IBM, however, they could very well do it. NDS would be a great integration tool for the many platforms and applications that IBM supports.
Linux, of course, would gain quite a bit from an open-source NDS.
There's a big difference between general learning in elementary school and getting work done in the real world. Challenges are good for learning, but tend to get in the way of actual productivity.
If your goal is to become intimately familiar with the operating system, then skipping the GUI and editing everything by hand is a good idea. If your goal is to write a couple of letters and play Quake, then it's a waste of time.
Just because you've chosen to specialize in a particular field, don't assume that it's best for everyone to follow the same path. I'd prefer that my doctors (for example) spend their time learning the fine details of medicine instead of writing shell scripts.
I disagree. Recruiting kernel hackers and Slashdot posters would net them some technical talent, but Linuxcare already has an abundance of that. What they're lacking is skilled managers and business leaders who could harness that talent and do something productive with it. Needless to say, those leaders would need to grasp the open-source concept and work well with the technical staff. But they wouldn't need to be (and probably shouldn't be) master-hackers in their own right.
Damn, I loved that game. Except I played it in CGA on a 4.77MHz IBM PC. It took about three seconds to move one step forward and five minutes to save the game. It was worth it, though.
Another great game in the genre was Space Rogue.
If I recall correctly, that was Esther Schindler.
Focusing on a single distribution makes QA and support a lot easier for them, and Red Hat on Intel gets them the bulk of the existing Linux installs (I figure Mandrake is close enough to be included).
This is an unfortunate side effect of the differentiation amongst distributions. The software will probably run fine on (for example) Debian/x86, but the cost of testing and supporting such a configuration far outweighs the potential revenue for an ISV. I'm hoping that the LSB will eventually smooth out these differences so that vendors can easily produce software that will run out of the box on any compliant distribution. That doesn't help alternate architectures, but at least it would put Linux on equal footing with Windows.
One thing about Linux that is a minor annoyance to me but a huge problem for the typical home user is the way device drivers are updated. If I install a random new peripheral under Win 98, the system detects the added hardware and asks for a driver disk. Since the disk generally comes with the peripheral, it's pretty easy for anyone to handle the install.
On the Linux side, I would typically have to upgrade my kernel to a version with support for that device. Or I would have to apply a patch to my kernel and recompile. These tasks are a lot easier now than in the old days, but they can be intimidating to new users and still present plenty of opportunity to screw up one's system.
I recall that there was some discussion among kernel developers about stabilizing a binary driver interface so that a precompiled driver module would work reliably with different kernel revisions. The argument which shot the idea down was that it would saddle the kernel with backwards compatibility issues and would encourage the development of binary-only drivers. I agree that these are both bad things, but I still feel that there needs to be some middle ground.
My initial thought here is that there should be a binary driver interface standard that evolves separately from the kernel proper. It's okay for it to change from time to time, but for the stable kernels there should probably be at least six months between revisions. Then perhaps we could establish a driver packaging format in which each package would include precompiled binary modules for multiple platforms (CPUs, SMP, etc.) and multiple versions of the driver interface standard. It could also include the driver source, so that the module could be compiled on the fly.
Obviously I've avoided most of the implementation issues here, but I would hope that this solution would make peripheral installation as easy for Linux users as it is for Windows users. It would also allow driver developers to work more independently of ongoing kernel development.
Derek
Your last point is the key. No matter how many user-friendly additions get incorporated into the mass-market Linux distributions, nothing is stopping the hardcore hackers from running Slackware and using vi as an all-purpose admin tool.
Some of these people remind me of MS advocates defending the company's right to control all computing. After all, if Windows, IE, Office, Bookshelf and the Sidewinder joystick aren't inextricably tied together, their freedom to avoid non-MS products is being threatened.
Derek
The people doing most of the flaming are not the ones who are doing the work of developing Linux. The latter group (including Linus himself) tends to be supportive of the sort of userspace developments that will be needed for Linux to achieve any kind of mainstream status.