Hear, hear... without having read the actual article, it sounds like Joy is extrapolating from current trends too much. It almost sounds like he saw, oh, I dunno, 'e' and thought, "oh, this is a nice line editor... maybe we can extrapolate from here and create a multi-line 'e'"... oh, hold on, he already did that;-)... (disclaimer: I am joking, I have the outmost respect for the man, and hjkl are as natural to me as, well, arrow keys;-)...
All the technologies he mentions are collaborative ones, i.e. they cannot be developed and/or applied by some mad scientist in a basement. They require organized, coherent team work. I.e., they do require rogue states, not rogue individuals.
More importantly, when something hits an extreme, it creates a backlash, a return towards equilibrium; that is true of society as much as it is for physical systems. When the Internet/technology/genetics will reach the edge of acceptable use/behavior, society will change to compensate. Look into the past: the Middle Ages created the Renaissance, the '50s brought the '60s, the '80s spawned the '90s... Our technological ethics will change to accommodate our technologies...
engineers never lie; we just approximate the truth.
(a) the ground effect is a very well understood phenonomenon, much more so than MAGLEV. In fact, the Russians/Ukrainians have built massive WIG aircraft, that were probably gonna be used for rapid troop landings. A quick Google finds this page.
(b) WIG has nothing to do with turbulence. In effect when a wing is closer to the ground, the space between the underside of the wing and the ground acts as a nozzle, i.e. increases air pressure much more so than the wing can do by itself (roughly 2x). Increased air pressure => higher lift (although I am over simplifying here).
(c) You don't have to have a large wingspan to take advantage of the ground effect. It just so happens, that when you fly slow, you can't produce as much difference in air pressure with a small wing, so you need a large one (again, I am over simplifying, but close enough). I.e. if you have lots of small wings, like these Japanese are trying to do, you're gonna get pretty much the same effect.
(d) The pterodactyles did not use the WIG effect... I mean come on, do you ever see illustrations of pterodactyles soaring at 2' off the ground?;-)...
I personally think this is a very interesting idea. Maglev is cool and all, but this can work just as well. If I had to find a weak spot it would be the total cost of ownership (TCO) of these things versus a Maglev train... with a maglev, electromagnets may cost more at installation, but after that you're pretty much done spending. OTOH, aircraft (particulary aircraft *engines*) are notoriously expensive to maintain...
engineers never lie; we just approximate the truth.
Re:To the 0wn3rz go the ComSats
on
R.I.P. Iridium
·
· Score: 2
AFAIK, Iridium cannot support data transmission --which is the primary reason McCaw opted not to bail them out, since he can't use their birds for Teledesic.
Iridium sounds like an idea that was planned by a bureacracy when cell phones weren't that widespread and by the time they got around to implement it, it was already obsolete...
I think there are 7yrs left to the useful life of their constellation --another company can't use them because they're proprietary, and they'd cost too much to take care of. My guess: USAF buys them at liquidation prices and tests their sat killers;-)...
engineers never lie; we just approximate the truth.
Hmmm... AOL has 'plays' in wireless, cable, DSL, and free PCs. They certainly have the money to do this. Most importantly, AOL has Mozilla.
Mozilla could be the Trojan Horse AOL needs to rid itself of Windows. Go read this article on Byte on programmable browsers. AOL could potentially rebuild its entire interface in Mozilla/XUL.
Then, not only they will be platform agnostic (with Mozilla doing the compatibility heavy-lifting) and connection agnostic (PPP? who needs PPP over a browser?), but could also potentially move away from being a consumer ISP, as they could pipe their proprietary content to a rebranded Mozilla at work (AOL@Work?). Then they could finally get the hits they need during daytime and business hours to truly be the #1 Internet site (bye, bye Netcenter?).
More importantly, AOL is smart enough to do this. And their stock has fallen 25% since the T-W take-over. Anyone else see an opportunity here?;-)...
engineers never lie; we just approximate the truth.
I am kinda dissappointed noone in this thread has mentioned Zsh.
Z-Shell is competitive with bash, and IIRC the comp.os.unix.shell FAQ shell comparison it actually has more features than any other shell out there. The new (still unstable version) even has dynamic module loading...
Plus, it's a (near) drop-in replacement for ksh and can even emulate some csh features for those that like them (search for the cshjunkie* options in the manual:-)
engineers never lie; we just approximate the truth.
Hear, hear... I repeated the same thing somewhere else on this discussion and a coupla older ones: we need to clean up the config files mess. And I even would go one further: clean up man files as well. Man files are an anachronism; they are not hypertext --no links-- and are not easily searchable. When every machine has a browser builtin, why are we still dealing with man files? Let's move manuals to some SGML/XML/HTML based format, that can be viewed through a browser and make 'man' a parser of that format for the old folk.
You could then even import annotations and errata on the documentation from the Net... look at how the PHP folk do their manual. It's the future of documentation folks...
But this is Open Source... let's stop bitching and day-dreaming; sit down and write code... who's hosting the CVS?;-)...
engineers never lie; we just approximate the truth.
All we'd need is a good DTD for Linux that will more or less follow the GNU options standard. Then, any application could extend the DTD for its own use.
You don't really have to agree on one DTD standard to see immediate benefits. One centralized XML-system parser that would read config files from one centralized XML depository would solve so many installation issues it's not funny. Think about this example: you're installing say PHP. PHP needs to know where Apache and MySQL are. Instead of bothering you with setting up the --with switches, the configure script calls the system XML library with say application("apache").source.path If it can't find it, it will tell you you need to install it --hey it could even go on the web and look for it... And the possibilities for online documentation and remote administration are too numerous to mention...
I think the two big issues with XML config files are: a) people think they're much uglier to edit than/etc files, b) most importantly, backwards compatibility. (a) IMNSHO is not an issue. Config files should be machine-readable first and human-readable second. Human-readability should only be important when things have gone wrong and you're SOL --under normal use you should use an XML aware config-tool (a meta-Linuxconf) to edit the files. Under emergency circumstances, you can still fire up vi and edit an XML file (unlike, say the Registry).
(b) is trickier. This is what I have proposed in an older/. thread: Let's create a centralized config directory, say/conf and a backwards compatibility deamon that monitors changes in/conf files. When an application and/or user changes a/conf file, the deamon parses the changes and writes out the appropriate/etc or/var file. I.e. during the transition period,/etc and/var will be read-only and/conf both read and write.
This is just a rough concept. But if there are any takers, let's do something about it... this is Linux people...
engineers never lie; we just approximate the truth.
Then you're doing something wrong... a 10-node PIII 550 Mhz System can stomp all over any RS/6000 out there. I administer a 16-node PIII-500 Beowulf and we routinely get Flops competitive to an Origin 2000 (for 1/30th of the price).
It all depends on: a) your application, b) your choice of networking hardware and software. Flops-intensive software will fare *very* well on a Beowulf. I/O-intensive stuff (like retrieving huge amounts of data off an RDBS) would most likely be better off on a mainframe.
The X standard is just windowing API. It has nothing to do with GUIs. Standards on an HCI (of which a GUI is a subset) are *needed*.
How can enforcing standards create bloat? you don't think what we have now is bloat: 2 desktop environments, a clone of an OS framework (GnuSTEP), 2 windowing APIs (X, Berlin coming up, and maybe even Y), and God knows how many WMs...
I like KDE (for now, I am not fanatic about it), but I also have to have GTK installed to get some apps... isn't that bloat?
And never mind the usability problem of people moving from machine to machine (or sometimes distro to distro) and having to re-invent the wheel again...
Repeat after me: Standards are GOOD. Any 3rd year engineering student will (well, *should*) tell you that...
engineers never lie; we just approximate the truth.
For those that haven't found the link: Nautilus.eazel.com. From their changelog it sounds like they're developing (or planning to in v1.1) system administration stuff. So, while GTK is platform-agnostic, I am thinking Eazel is focusing exclusively on Linux. OTOH, it will be GPL'ed, so you can port their tools...
engineers never lie; we just approximate the truth.
Good points; lemme see: a)Yes, in the begginning you would solve the same problem --figure out where everything should go. But when you do put the 'meta-structure' into place, you won't have to do it ever again. A RedHat distribution's meta-structure should have the same data as a Debian's, as a home-brew. On any CPU.
b) OK; I may have not been totally clear; no application should hold information about others. It should only contain information about itself. So, if it does make the wrong assumptions, it will only break itself. For example, say you're installing an Apache module. The module installation will go to the central depository (I favor/conf) and look for say/conf/apache/main.xml and then source.path or something. Then it will know how to compile itself w/o having to be told --with-apache=...
But that's just replicating existing functionality... Think of how easy it would be to build a universal GUI for *anything* on top of/conf. The module's developer wouldn't have to worry about a GTK interface or a KDE one or one in Lesstif or or SVGAlib... One parser/GUI to rule them all;-)... One library to parse config files... Take the grudge work out of the developers and let them create utilities/applications.
The Windows way is flawed: the Registry is not human-editable (at least not easily) or intuitive. The dll's have to be centralized and get all mangled up. Unix can leapfrog Windows now: XML config files, and well, symlinks;-)...
What I am proposing is a redesign (which I know will be a pain in the ass during the transition period). What we have *now* is an ad hoc system --which doesn't work.
engineers never lie; we just approximate the truth.
The problem with current Unix systems is not just the packaging; it's configuration. Unix's great strength is its flexibility, adaptablity, and yes its own bizarre OO-design (everything's a file).
When you have something that flexible, you need to account for all the different configurations and setups people can and will make to the system. That's what autoconf does for builds and the package managers are trying to do for installs. But that's solving the wrong problem: you're effectively solving a design issue with workarounds, with duct tape and paperclips.
What needs to be done, is for Unix/Linux to apply what years of experience have taught 'hardware' engineers: when you have flexible configurations, you need a configuration management system. The RPM database is not enough.
What we need, is a registry-like, centralized repository of information about the system, in a standardized language that: a) can *very* easily be read by software (a la Registry), and b) can as a last resort be edited by humans with minimum tools (a la Unix/etc files). I propose (and have, again and again) XML.
Imagine you're working on a system that doesn't have an/etc or a/var or an RPM database. What it does have is a way for you and *all* the software on your system to introspect, and find out properties of other software on your system (via some secure mechanism, of course).
Thus, a new package can find out where it can install itself and how to link to everything it needs, without messing with system-level software. Not only that, but since the meta-information for everything is gonna be sitting right there, the software can not only resolve dependencies but also suggest configuration changes in its dependencies! And since all that will be in a parsable structure, you should be/would be able to go on the Net and find out the answer to the exact problem.
Just dreamin...
engineers never lie; we just approximate the truth.
IMHO, there are different visions of the future of Linux in the community. There are some who want Linux to stand for something and then, there's the camp who envisions Linux as a platform. Supposedly, on this open, free platform a whole buncha companies can contribute and/or base their products on.
I dunno what you, or most of/. is thinking, but I am with the second camp. I hope some wealthy organizations (i.e. big companies) want to implement features in Linux --only, they won't ask for them, OSS means they will go ahead and build them. And OSS means, that if their implementations suck, the source to fix them would be/should be there.
I for one, do not consider OSS a political platform, but an engineering approach --one that brings the transparency of mechanical engineering systems to software. In the mechanical world, your designs are still patented and/or commercializable, but the design is open for everyone to learn from and/or modify. This is what software "engineering" needs, now.
I mostly agree with the article: if Linux wants to become friendly to end-users (a big if), then we need commercial-level engineering practices. Which means deadlines, project management, etc., etc. There are bad things (such as the feature creep you mention) associated with these practices, but the positive aspects outweigh them.
engineers never lie; we just approximate the truth.
Not entirely correct; The Word re-versioning brought all Word versions to the same number; at that point, IIRC, there was Word for DOS 5.2 (because of WP 5.1;-), Word for Mac 5.4 (or 4.5?) and finally Word for Windows 2.0. Which was moronic of course, sine WfW was more advanced than the DOS version...
engineers never lie; we just approximate the truth.
Of course you're right... I mean come on, anybody who has been sleep-deprived for a substantial period of time can testify that there is no worse feeling.
True story: I've been through officer training for a certain Army (er... figure it out). As trainees we were sleep-deprived for 4 weeks: an average 5 hrs of sleep a day, with an occasional Sunday 6 or 7 --this while exercising 4-5 hours a day, doing chores, being on duty, etc. etc, for the remainder of the day... During Week 3 I was sitting in a nice, cozy, warm room taking notes for some class. At that point, I was halucinating at night or early in the morning pretty regulary (in fact this was a common experience among my class-mates). But that day, while I was taking notes, I fell asleep. Writing. Notes. I was woken up --by my trainer no less-- and found out that I had written down my dream/halucination/what have you. Not much, a dozen words or so and then a squiggly line trailing off...
I should have kept that notebook. But I have never been more scared for my own well being before or since.
Yeah, you go and try out the poster's theory...
engineers never lie; we just approximate the truth.
Nitpick: Intel's ticker is INTC. INTL is someone else... common enough mistake... would be interesting to compare volume on INTC with volume on INTL and see how many people make that little innocent typo;-)...
engineers never lie; we just approximate the truth.
You're missing something: the biggest driver for Beowulf-class systems is the infamous price-to-performance ratio, not pure FLOPS. How are you gonna get better price-to-performance? with commodity hardware (i.e. low price) that has been designed for maximum performance.
A Crusoe may fulfill the former criterion (their prices sure seem low enough) but it fails on the latter. A Pentium III- (or even a Celeron-) class CPU, however fulfills both. Now, if Transemta decides to use their technology for a CPU designed for pure speed, I could see how a Beowulf of those things may prove competitive, as long as it doesn't rely on non-commodity hardware (particulary motherboards and NICs).
engineers never lie; we just approximate the truth.
I don't have personal first-hand experience, but AFAIK, at least Canada's policies are much better than the US's.
As far as the lottery is concerned: yes, getting in this way doesn't give you 'bragging rights' (I get envious, 'you bastard' looks from fellow immigrants most of the time) but it can be potentially much faster. I wouldn't rely on the DV visas (I didn't; I was already in with an H-1) but it can save you a lot of trouble and money, especially if you're European (which greatly improves your odds).
Which is another point: the DV visas are free at least money-wise (the time and anxiety have to count for something). Don't get swindled by those 'agencies' that advertise in the back of international magazines (like the int'l edition Time or Newsweek). Besides airfare to go back home for a few days (which I was planning to any ways), total cost of processing, medical exams, etc. was ~$500. Compare this to an H-1 based GC which will cost you several times that, just in lost wages since you're gonna be tied to your employer. And we're not talking a little 'bit' of money here; the difference can be as much as 100% more in salary. I know PhDs in engineering from first-tier US colleges that work in their field for less than $50k. That's just wrong.
(And before someone starts to cry: "oh, that's $50k more than they'd make back home", think: they have to pay huge phone/travel bills, their credit sucks, so do their loans/mortgages, their spouses/children usually can't work until they learn the language, if ever, and they're stuck in the same job like it or not. Why? don't they add to this economy?)
engineers never lie; we just approximate the truth.
If you are from a low-immigration country (i.e. from Western and Cenral Europe, Oceania, etc) you might be better off trying for the DV visas, i.e. lottery visas. That was my ticket to a Green Card. The odds for a European are actually good (one in 12 I think) and the maximum processing time (i.e. mail-in of the lottery entry to actual Green Card) is at most 24 months.
If you have the option to go for GC (Adjustment of Status) processing to your home country, go for it. Embassies usually have to deal with fewer applications and are easier to get a handle of than the INS. If you have a good chance to get the GC (most people do), you don't even have to worry about your current visa.
Check out misc.immigration.usa on Usenet. A great medium-traffic forum (hopefully it will still be after being mentioned here) with a lot of old-timer immigrants that already have been through most of the INS bureacracy.
As for the whiners: INS is by far the worst US government service. It's quite easy to suck this bad when the people you deal with have no political power whatsoever. Maybe we should get a PAC going;-)...
engineers never lie; we just approximate the truth.
Telecommunication and transportation infrastructure is what improves wealth, education and peace; not the other way around.
Look in your back yard: the interstate highway system in the US was built when the US economy was doing rather poorly; yet it stimulated growth and development. What exactly was California before the coast-to-coast rail lines were built? Definitely not the 7th largest economy in the world...
That is what creates wealth: Free Trade, Free Speech. Just imagine how irrelevant the US would be in the world today without proper telecomm and transportation infrastructure. After all, America (OK, Australia too) is the only non-contiguous land mass on this planet.
engineers never lie; we just approximate the truth.
Slightly off-topic: Did anybody else notice that moderation was quirky yesterday? there were decent posts moderated down all over the place.
Now, I aint the cynical kind (yes I am), but this phenomenon coming a few days after the Slash release makes me sceptical: is it possible that some group o' kids found themselves a moderation exploit in/.? I haven't tested the 0.9 code, but it was definitely a possibility in 0.3...
engineers never lie; we just approximate the truth.
I am bothered by this argument. All day I use a language that allows n-D array addition in the equivalent of C=A+B. There are more parameters in there than immediately apparent. E.g. what do you do if A(i,j) is undefined while B(i,j) has data? do you add 0 to B(i,j)? do you keep the result undefined, as that position may be non-sensical for the result? What do you add across? In the applications I use, we end up replicating native concepts like the above, in ANSI-C to get the performance we need.
I love the idea of a next-generation language like the author describes. But, in my experience, we're sitting in that grey period between technologies, where the old technology (C++, Java) is showing its 'stretchmarks' while the new generation (?) isn't ready for prime-time yet.
engineers never lie; we just approximate the truth.
Slashdot Mirror
Hear, hear... without having read the actual article, it sounds like Joy is extrapolating from current trends too much. It almost sounds like he saw, oh, I dunno, 'e' and thought, "oh, this is a nice line editor... maybe we can extrapolate from here and create a multi-line 'e'"... oh, hold on, he already did that ;-)... (disclaimer: I am joking, I have the outmost respect for the man, and hjkl are as natural to me as, well, arrow keys ;-)...
All the technologies he mentions are collaborative ones, i.e. they cannot be developed and/or applied by some mad scientist in a basement. They require organized, coherent team work. I.e., they do require rogue states, not rogue individuals.
More importantly, when something hits an extreme, it creates a backlash, a return towards equilibrium; that is true of society as much as it is for physical systems. When the Internet/technology/genetics will reach the edge of acceptable use/behavior, society will change to compensate. Look into the past: the Middle Ages created the Renaissance, the '50s brought the '60s, the '80s spawned the '90s... Our technological ethics will change to accommodate our technologies...
engineers never lie; we just approximate the truth.
Alright... let me start debunking:
;-)...
(a) the ground effect is a very well understood phenonomenon, much more so than MAGLEV. In fact, the Russians/Ukrainians have built massive WIG aircraft, that were probably gonna be used for rapid troop landings. A quick Google finds this page.
(b) WIG has nothing to do with turbulence. In effect when a wing is closer to the ground, the space between the underside of the wing and the ground acts as a nozzle, i.e. increases air pressure much more so than the wing can do by itself (roughly 2x). Increased air pressure => higher lift (although I am over simplifying here).
(c) You don't have to have a large wingspan to take advantage of the ground effect. It just so happens, that when you fly slow, you can't produce as much difference in air pressure with a small wing, so you need a large one (again, I am over simplifying, but close enough). I.e. if you have lots of small wings, like these Japanese are trying to do, you're gonna get pretty much the same effect.
(d) The pterodactyles did not use the WIG effect... I mean come on, do you ever see illustrations of pterodactyles soaring at 2' off the ground?
I personally think this is a very interesting idea. Maglev is cool and all, but this can work just as well. If I had to find a weak spot it would be the total cost of ownership (TCO) of these things versus a Maglev train... with a maglev, electromagnets may cost more at installation, but after that you're pretty much done spending. OTOH, aircraft (particulary aircraft *engines*) are notoriously expensive to maintain...
engineers never lie; we just approximate the truth.
AFAIK, Iridium cannot support data transmission --which is the primary reason McCaw opted not to bail them out, since he can't use their birds for Teledesic.
;-)...
Iridium sounds like an idea that was planned by a bureacracy when cell phones weren't that widespread and by the time they got around to implement it, it was already obsolete...
I think there are 7yrs left to the useful life of their constellation --another company can't use them because they're proprietary, and they'd cost too much to take care of. My guess: USAF buys them at liquidation prices and tests their sat killers
engineers never lie; we just approximate the truth.
Hmmm... AOL has 'plays' in wireless, cable, DSL, and free PCs. They certainly have the money to do this. Most importantly, AOL has Mozilla.
;-)...
Mozilla could be the Trojan Horse AOL needs to rid itself of Windows. Go read this article on Byte on programmable browsers. AOL could potentially rebuild its entire interface in Mozilla/XUL.
Then, not only they will be platform agnostic (with Mozilla doing the compatibility heavy-lifting) and connection agnostic (PPP? who needs PPP over a browser?), but could also potentially move away from being a consumer ISP, as they could pipe their proprietary content to a rebranded Mozilla at work (AOL@Work?). Then they could finally get the hits they need during daytime and business hours to truly be the #1 Internet site (bye, bye Netcenter?).
More importantly, AOL is smart enough to do this. And their stock has fallen 25% since the T-W take-over. Anyone else see an opportunity here?
engineers never lie; we just approximate the truth.
I hate to reply to my own post, but I managed to dig up the comp.os.unix.shell FAQ posting on shell comparisons: here.
Definetely worth a look for those shopping for a shell...
engineers never lie; we just approximate the truth.
I am kinda dissappointed noone in this thread has mentioned Zsh.
:-)
Z-Shell is competitive with bash, and IIRC the comp.os.unix.shell FAQ shell comparison it actually has more features than any other shell out there. The new (still unstable version) even has dynamic module loading...
Plus, it's a (near) drop-in replacement for ksh and can even emulate some csh features for those that like them (search for the cshjunkie* options in the manual
engineers never lie; we just approximate the truth.
Hmmm... all I could come up with in a moment's notice was this. A Unit converter that can do about 50 units or so in 5 different categories...
:-).
(OK, so I had this to work from, but it was too big at 20k
engineers never lie; we just approximate the truth.
Hear, hear... I repeated the same thing somewhere else on this discussion and a coupla older ones: we need to clean up the config files mess. And I even would go one further: clean up man files as well. Man files are an anachronism; they are not hypertext --no links-- and are not easily searchable. When every machine has a browser builtin, why are we still dealing with man files? Let's move manuals to some SGML/XML/HTML based format, that can be viewed through a browser and make 'man' a parser of that format for the old folk.
;-)...
You could then even import annotations and errata on the documentation from the Net... look at how the PHP folk do their manual. It's the future of documentation folks...
But this is Open Source... let's stop bitching and day-dreaming; sit down and write code... who's hosting the CVS?
engineers never lie; we just approximate the truth.
All we'd need is a good DTD for Linux that will more or less follow the GNU options standard. Then, any application could extend the DTD for its own use.
/etc files, b) most importantly, backwards compatibility. (a) IMNSHO is not an issue. Config files should be machine-readable first and human-readable second. Human-readability should only be important when things have gone wrong and you're SOL --under normal use you should use an XML aware config-tool (a meta-Linuxconf) to edit the files. Under emergency circumstances, you can still fire up vi and edit an XML file (unlike, say the Registry).
/. thread: Let's create a centralized config directory, say /conf and a backwards compatibility deamon that monitors changes in /conf files. When an application and/or user changes a /conf file, the deamon parses the changes and writes out the appropriate /etc or /var file. I.e. during the transition period, /etc and /var will be read-only and /conf both read and write.
You don't really have to agree on one DTD standard to see immediate benefits. One centralized XML-system parser that would read config files from one centralized XML depository would solve so many installation issues it's not funny. Think about this example: you're installing say PHP. PHP needs to know where Apache and MySQL are. Instead of bothering you with setting up the --with switches, the configure script calls the system XML library with say application("apache").source.path If it can't find it, it will tell you you need to install it --hey it could even go on the web and look for it... And the possibilities for online documentation and remote administration are too numerous to mention...
I think the two big issues with XML config files are: a) people think they're much uglier to edit than
(b) is trickier. This is what I have proposed in an older
This is just a rough concept. But if there are any takers, let's do something about it... this is Linux people...
engineers never lie; we just approximate the truth.
Then you're doing something wrong... a 10-node PIII 550 Mhz System can stomp all over any RS/6000 out there. I administer a 16-node PIII-500 Beowulf and we routinely get Flops competitive to an Origin 2000 (for 1/30th of the price).
It all depends on: a) your application, b) your choice of networking hardware and software. Flops-intensive software will fare *very* well on a Beowulf. I/O-intensive stuff (like retrieving huge amounts of data off an RDBS) would most likely be better off on a mainframe.
Check out this site and tune up your cluster...
engineers never lie; we just approximate the truth.
The X standard is just windowing API. It has nothing to do with GUIs. Standards on an HCI (of which a GUI is a subset) are *needed*.
How can enforcing standards create bloat? you don't think what we have now is bloat: 2 desktop environments, a clone of an OS framework (GnuSTEP), 2 windowing APIs (X, Berlin coming up, and maybe even Y), and God knows how many WMs...
I like KDE (for now, I am not fanatic about it), but I also have to have GTK installed to get some apps... isn't that bloat?
And never mind the usability problem of people moving from machine to machine (or sometimes distro to distro) and having to re-invent the wheel again...
Repeat after me: Standards are GOOD. Any 3rd year engineering student will (well, *should*) tell you that...
engineers never lie; we just approximate the truth.
For those that haven't found the link: Nautilus.eazel.com. From their changelog it sounds like they're developing (or planning to in v1.1) system administration stuff. So, while GTK is platform-agnostic, I am thinking Eazel is focusing exclusively on Linux. OTOH, it will be GPL'ed, so you can port their tools...
engineers never lie; we just approximate the truth.
Good points; lemme see:
/conf) and look for say /conf/apache/main.xml and then source.path or something. Then it will know how to compile itself w/o having to be told --with-apache=...
/conf. The module's developer wouldn't have to worry about a GTK interface or a KDE one or one in Lesstif or or SVGAlib... One parser/GUI to rule them all ;-)... One library to parse config files... Take the grudge work out of the developers and let them create utilities/applications.
;-)...
a)Yes, in the begginning you would solve the same problem --figure out where everything should go. But when you do put the 'meta-structure' into place, you won't have to do it ever again. A RedHat distribution's meta-structure should have the same data as a Debian's, as a home-brew. On any CPU.
b) OK; I may have not been totally clear; no application should hold information about others. It should only contain information about itself. So, if it does make the wrong assumptions, it will only break itself. For example, say you're installing an Apache module. The module installation will go to the central depository (I favor
But that's just replicating existing functionality... Think of how easy it would be to build a universal GUI for *anything* on top of
The Windows way is flawed: the Registry is not human-editable (at least not easily) or intuitive. The dll's have to be centralized and get all mangled up. Unix can leapfrog Windows now: XML config files, and well, symlinks
What I am proposing is a redesign (which I know will be a pain in the ass during the transition period). What we have *now* is an ad hoc system --which doesn't work.
engineers never lie; we just approximate the truth.
The problem with current Unix systems is not just the packaging; it's configuration. Unix's great strength is its flexibility, adaptablity, and yes its own bizarre OO-design (everything's a file).
/etc files). I propose (and have, again and again) XML.
/etc or a /var or an RPM database. What it does have is a way for you and *all* the software on your system to introspect, and find out properties of other software on your system (via some secure mechanism, of course).
When you have something that flexible, you need to account for all the different configurations and setups people can and will make to the system. That's what autoconf does for builds and the package managers are trying to do for installs. But that's solving the wrong problem: you're effectively solving a design issue with workarounds, with duct tape and paperclips.
What needs to be done, is for Unix/Linux to apply what years of experience have taught 'hardware' engineers: when you have flexible configurations, you need a configuration management system. The RPM database is not enough.
What we need, is a registry-like, centralized repository of information about the system, in a standardized language that: a) can *very* easily be read by software (a la Registry), and b) can as a last resort be edited by humans with minimum tools (a la Unix
Imagine you're working on a system that doesn't have an
Thus, a new package can find out where it can install itself and how to link to everything it needs, without messing with system-level software. Not only that, but since the meta-information for everything is gonna be sitting right there, the software can not only resolve dependencies but also suggest configuration changes in its dependencies! And since all that will be in a parsable structure, you should be/would be able to go on the Net and find out the answer to the exact problem.
Just dreamin...
engineers never lie; we just approximate the truth.
IMHO, there are different visions of the future of Linux in the community. There are some who want Linux to stand for something and then, there's the camp who envisions Linux as a platform. Supposedly, on this open, free platform a whole buncha companies can contribute and/or base their products on.
/. is thinking, but I am with the second camp. I hope some wealthy organizations (i.e. big companies) want to implement features in Linux --only, they won't ask for them, OSS means they will go ahead and build them. And OSS means, that if their implementations suck, the source to fix them would be/should be there.
I dunno what you, or most of
I for one, do not consider OSS a political platform, but an engineering approach --one that brings the transparency of mechanical engineering systems to software. In the mechanical world, your designs are still patented and/or commercializable, but the design is open for everyone to learn from and/or modify. This is what software "engineering" needs, now.
I mostly agree with the article: if Linux wants to become friendly to end-users (a big if), then we need commercial-level engineering practices. Which means deadlines, project management, etc., etc. There are bad things (such as the feature creep you mention) associated with these practices, but the positive aspects outweigh them.
engineers never lie; we just approximate the truth.
Not entirely correct; The Word re-versioning brought all Word versions to the same number; at that point, IIRC, there was Word for DOS 5.2 (because of WP 5.1 ;-), Word for Mac 5.4 (or 4.5?) and finally Word for Windows 2.0. Which was moronic of course, sine WfW was more advanced than the DOS version...
engineers never lie; we just approximate the truth.
Of course you're right... I mean come on, anybody who has been sleep-deprived for a substantial period of time can testify that there is no worse feeling.
True story: I've been through officer training for a certain Army (er... figure it out). As trainees we were sleep-deprived for 4 weeks: an average 5 hrs of sleep a day, with an occasional Sunday 6 or 7 --this while exercising 4-5 hours a day, doing chores, being on duty, etc. etc, for the remainder of the day... During Week 3 I was sitting in a nice, cozy, warm room taking notes for some class. At that point, I was halucinating at night or early in the morning pretty regulary (in fact this was a common experience among my class-mates). But that day, while I was taking notes, I fell asleep. Writing. Notes. I was woken up --by my trainer no less-- and found out that I had written down my dream/halucination/what have you. Not much, a dozen words or so and then a squiggly line trailing off...
I should have kept that notebook. But I have never been more scared for my own well being before or since.
Yeah, you go and try out the poster's theory...
engineers never lie; we just approximate the truth.
Nitpick: Intel's ticker is INTC. INTL is someone else... common enough mistake... would be interesting to compare volume on INTC with volume on INTL and see how many people make that little innocent typo ;-)...
engineers never lie; we just approximate the truth.
You're missing something: the biggest driver for Beowulf-class systems is the infamous price-to-performance ratio, not pure FLOPS. How are you gonna get better price-to-performance? with commodity hardware (i.e. low price) that has been designed for maximum performance.
A Crusoe may fulfill the former criterion (their prices sure seem low enough) but it fails on the latter. A Pentium III- (or even a Celeron-) class CPU, however fulfills both. Now, if Transemta decides to use their technology for a CPU designed for pure speed, I could see how a Beowulf of those things may prove competitive, as long as it doesn't rely on non-commodity hardware (particulary motherboards and NICs).
engineers never lie; we just approximate the truth.
I don't have personal first-hand experience, but AFAIK, at least Canada's policies are much better than the US's.
As far as the lottery is concerned: yes, getting in this way doesn't give you 'bragging rights' (I get envious, 'you bastard' looks from fellow immigrants most of the time) but it can be potentially much faster. I wouldn't rely on the DV visas (I didn't; I was already in with an H-1) but it can save you a lot of trouble and money, especially if you're European (which greatly improves your odds).
Which is another point: the DV visas are free at least money-wise (the time and anxiety have to count for something). Don't get swindled by those 'agencies' that advertise in the back of international magazines (like the int'l edition Time or Newsweek). Besides airfare to go back home for a few days (which I was planning to any ways), total cost of processing, medical exams, etc. was ~$500. Compare this to an H-1 based GC which will cost you several times that, just in lost wages since you're gonna be tied to your employer. And we're not talking a little 'bit' of money here; the difference can be as much as 100% more in salary. I know PhDs in engineering from first-tier US colleges that work in their field for less than $50k. That's just wrong.
(And before someone starts to cry: "oh, that's $50k more than they'd make back home", think: they have to pay huge phone/travel bills, their credit sucks, so do their loans/mortgages, their spouses/children usually can't work until they learn the language, if ever, and they're stuck in the same job like it or not. Why? don't they add to this economy?)
engineers never lie; we just approximate the truth.
Official US Visa Site
If you are from a low-immigration country (i.e. from Western and Cenral Europe, Oceania, etc) you might be better off trying for the DV visas, i.e. lottery visas. That was my ticket to a Green Card. The odds for a European are actually good (one in 12 I think) and the maximum processing time (i.e. mail-in of the lottery entry to actual Green Card) is at most 24 months.
If you have the option to go for GC (Adjustment of Status) processing to your home country, go for it. Embassies usually have to deal with fewer applications and are easier to get a handle of than the INS. If you have a good chance to get the GC (most people do), you don't even have to worry about your current visa.
Check out misc.immigration.usa on Usenet. A great medium-traffic forum (hopefully it will still be after being mentioned here) with a lot of old-timer immigrants that already have been through most of the INS bureacracy.
;-)...
As for the whiners: INS is by far the worst US government service. It's quite easy to suck this bad when the people you deal with have no political power whatsoever. Maybe we should get a PAC going
engineers never lie; we just approximate the truth.
Telecommunication and transportation infrastructure is what improves wealth, education and peace; not the other way around.
Look in your back yard: the interstate highway system in the US was built when the US economy was doing rather poorly; yet it stimulated growth and development. What exactly was California before the coast-to-coast rail lines were built? Definitely not the 7th largest economy in the world...
That is what creates wealth: Free Trade, Free Speech. Just imagine how irrelevant the US would be in the world today without proper telecomm and transportation infrastructure. After all, America (OK, Australia too) is the only non-contiguous land mass on this planet.
engineers never lie; we just approximate the truth.
Yep; same here: IE5 on NT4 (I am at work, alright? ;-)
engineers never lie; we just approximate the truth.
Slightly off-topic: Did anybody else notice that moderation was quirky yesterday? there were decent posts moderated down all over the place.
/.? I haven't tested the 0.9 code, but it was definitely a possibility in 0.3...
Now, I aint the cynical kind (yes I am), but this phenomenon coming a few days after the Slash release makes me sceptical: is it possible that some group o' kids found themselves a moderation exploit in
engineers never lie; we just approximate the truth.
I am bothered by this argument. All day I use a language that allows n-D array addition in the equivalent of C=A+B. There are more parameters in there than immediately apparent. E.g. what do you do if A(i,j) is undefined while B(i,j) has data? do you add 0 to B(i,j)? do you keep the result undefined, as that position may be non-sensical for the result? What do you add across? In the applications I use, we end up replicating native concepts like the above, in ANSI-C to get the performance we need.
I love the idea of a next-generation language like the author describes. But, in my experience, we're sitting in that grey period between technologies, where the old technology (C++, Java) is showing its 'stretchmarks' while the new generation (?) isn't ready for prime-time yet.
engineers never lie; we just approximate the truth.