OK, fine; really, the format here is almost beside the point. I am sure that whatever group gets to decide on the format will be knowledgable enough to decide on something practical and readable for both machines and humans.
The more important thing here, is that: a) the community (not necessarily us, this thread, or/. for that matter) agree that it is about time to move to a standardized format, and b) that this migration is as painless as possible. Let's agree on that, and get a momentum behind this. The engineering details warrant a larger audience and a much longer discussion...
engineers never lie; we just approximate the truth.
No, I wasn't; but please, read a few lines further: I wasn't suggesting that config files should be locked out --just that/etc and/var should be locked out while we migrate to/conf (or whatever it gets to be called)./conf and its config files (the standardized config files) would and should be editable by the user.
But as someone else suggested in this thread,/conf should be more like AIX's config files, or sorta like/proc: real text files, but changes in them should be detectable by some backward-compatibility deamon, that would parse the new file and write an old-format/etc or/var file. As more and more programs migrate to the new standardized format, the need for still having/etc and/var around will die of. Sorta like the.ini -> registry migration in Windows. But without the Windows stupidity of making the registry uneditable and unreadable by a human --or, for that matter, uneditable w/o a specialized tool.
With careful engineering and everybody pulling together (which, with the added benefits of a standard format to users and developers alike won't be too hard, IMHO), we could have a clean, standardized system in 2-3 years easily...
engineers never lie; we just approximate the truth.
Yes, XML is ugly and not as effient as those #s and;s... but: XML is already agreed upon and "out there"; there is no need to come up with Yet Another Standard. More importantly, XML's "loose" enough to cover every configuration file need _I_ can think of (not that that's saying much, BTW;-)...
E.g.: Apache's.conf syntax is XMLish enough, IMHO: it's parsable, human-readable and -editable. And your argument that text editors are mature and we should stick to text applies both ways: modern editors (emacs, vim) are mature enough to handle a text-based, XML-like language with little added user work. Added benefit: since everything will be standardized and immediately parsable, you could probably click/Ctrl-] on a config parameter and get that man file entry you want... vim can be made to do it now...
We can do XML-based config files now, with existing tools, without departing too much from the "Unix way". I think it's time we should. Think about it: before Bill Joy, unix admins probably thought one line of text at a time was all _they_ needed;-)...
engineers never lie; we just approximate the truth.
Of course, you're right: backwards compatibility is a bitch. But why can't we work around it? MS did (sort of), why not Linux?
My $0.002: forget/etc,/var --let's make them forbitten territory, locked out to any user, including root (sorta like/proc). Instead, let's agree on say/conf, and create a config-service deamon that will read from/conf in an agreed-upon, standardized format and write to/etc,/var, etc. for backwards compatibility. When/etc and/var become irrelevant, get rid of them completely...
As for the format; yeah, it will be tough to iron out, but so was POSIX. I ain't that level of hacker, but I do think that XML should be able to handle everything that a program would need. After all, XML is more of a syntax than a language, right? The added benefits:
As I said before, a GUI layer on top will be almost trivial, and expandable to no end.
There could be a standard configuration-reading library, that any utils developer can use to parse his or her config file, saving that stupid work... (I've always hated writing parsers, don't you?;-)
engineers never lie; we just approximate the truth.
I'll go one step further: we don't just need more feedback from admintools (actually, I agree with the two-layer approach: a high-level, newbie layer and a lower-level, expert layer of feedback): we need bette configuration files. There was an idea being thrown around in a previous/. discussion for standardizing on an XML-derived config syntax. Now, wouldn't that be nice? Standardized config-files with parsable comments... a GUI layer would be only a parser away.
engineers never lie; we just approximate the truth.
Why is a GUI a bad thing? I totally disagree with you that the GUI and the need to things the 'pretty' way is what makes Windows unstable. What makes Windows unstable is that it is a huge engineering effort, accomplished by one company and closed to outside scrutiny. It's like Ford kept developing cars with the hoods shut off and explossives triggered to the hood;-)...
GUIs are good. Humans primarily rely on visual information, not a buncha #s and;s and ugly Unix-y text files. I've been administering/using Unix boxes for a decade now: I am sick, sick and tired of all the different little syntaxes and quirks thrown into every configuration file (Sendmail is the champion of quirkiness, of course).
Stop the madness! You can/should/have to standardize... even win16 had a consistent *.ini file syntax that made sense even if you had never seen the application before. Why can't Unix standardize? why not Linux? not only it will help admins, it will make the creation of a GUI layer on top, much, much easier. As things are now, every utility needs a parser to make sense out of its config file...
Better stop ranting now... I am going back to my POS 98 laptop, fondly remembering the days when a reliable, pretty, configurable Unix still existed: it was called NeXTStep:-(...
engineers never lie; we just approximate the truth.
Yeajh, but DVD's can be much, much cheaper than VHS tapes, so there wouldn't be an inventory issue; you wouldn't return the disks so that the store had enough to give out, but just to recycle them. Plus, in that scheme, with a decent return rate, you could probably charge $2-$3 a disk...
The medium becomes practically free, the cost to keep tracks of them dwindles down --no need for bar-scanners, minimum-wage-paid attendands, DBs of customer data...
But those advantages exist in this idea as well... Hell, why even have a store? put them into a vending machine and you're done. This can kill Blockbuster;-)...
It's that damn non-degradable plastic that sucks...
engineers never lie; we just approximate the truth.
Now, if they could figure a way to turn the coating back to transparency with some special laser, so landfills don't get crammed up with this suckers, I'd be all for it.
Think about it... you could be sitting at the checkout line in a grocery store, see a movie you missed and buy it for $3-4 without worrying about special players, returning times, and all that crap...
engineers never lie; we just approximate the truth.
I too have to give my props to HP LaserJets. An amusing anecdote back from the days when computer support paid my college tuition:
My college at the time had several high-end HP LJ III (x?). Their expected engine life-time (I guess MTBF) was ~250,000 pages. So, one day, my supervisor comes by and he wants to open two of them up and clean the dust out (no instructions for that, BTW:-). So, we print a test-page on both. One had printed ~1,200,000 (that's 1.2 MILLION pages) and the other ~700,000... After playing with the screws and the covers, we open one up. The motherboard was literally under a 1/2" blanket of dust. I mean solid dust that came off like a piece of cloth. We cleaned those guys up, and as far as I know they were still chugging along after I graduated;-)...
After that I always recommend an HP...
engineers never lie; we just approximate the truth.
Probably one of the few truely great ideas in the Web development industry. It means freedom from client peculiarities --forget about all writing for all those different browsers again and again, just one huge translator template will (e.g. XML->Opera-compatible HTML, or IE-compatible HTML or AvantGO, etc). It means that potentially the same server can be serving not only PCs, laptops, PDAs and the like, but also other software, by reading plain XML, or some subset of it.
In the OSS arena, the best example of XML on the server=>HTML (or for that matter anything else) on the client is Cocoon. I played around with Cocoon 1.x a little bit and it's very impressive architecturally, but even the principals agree that the performance isn't there yet. I am eagerly awaiting for Coccoon 2 though;-)...
engineers never lie; we just approximate the truth.
I will repeat this until I am soar, 'coz, well, it's a soar point with us in the Beowulf community: Linux SMP sucks. If you want good SMP performance, you're better of with NT or Solaris.
The big problem with Linux SMP, IMNSHO: NO CPU affinity. Which means roughly this: processes are rotated thru all available CPUs, instead of being assigned to one CPU and then being dynamically balanced (new jobs sent to the lightest-used CPU, when CPUs are imbalanced by some threshold %, move 1-2 smaller jobs that will balance them out).
What does this mean? well, CPU cache is practically useless. Makes all that dough spent on Xeons instead of Celerons seem wasted --and it is.
Don't get me wrong; I am all for Linux, and I am sure SMP will catch up pretty soon. But don't go spending $$$ on SMP machines expecting (n-1)*100% increase in performance.
engineers never lie; we just approximate the truth.
A ticker symbol is enough, IMNSHO... for one thing, consider all those people (I know a few myself) that sign for every IPO E*Trade or some other online broker offers in the hope they'll make money not from the company's value, but other traders' idiocy.
The market as it is now, especially the high-tech Internet market (never mind the Linux one) is one big Ponzi scheme. And as any Ponzi scheme its success or failure doesnt depend on economics but perception, in which case, a cute ticker symbol may be all you need.
LinuxOne isn't even the worst one... eHow.com (or was it HowTo.com or How2.com?) filed for an IPO selling themselves as a portal while their revenue came from rebate processing offline. And then there was that ISP (eff-something or other) that had no revenue, no infrastructure, no clients, just some hot-shot big-name CEO, and they filed an S-1 claiming that they will use the proceeds to buy other, real ISPs... I just hope that this lunacy continues till I vest;-) (and that's exactly the point, isn't it?)
engineers never lie; we just approximate the truth.
Re:AOL Time Warner not a monopoly.
on
AOL Nation
·
· Score: 2
Hear, hear... Completely agreed. This is a merger of interests, a conglomerate not a monopoly in any means. I would put it this way: AOL is gonna be to the Internet what Sony is to consumer electronics: an infrastructure company that has the content to attract people to its services and technologies. Nothing more, nothing less.
And that's probably not a bad thing --in the same way that Sony can throw the wight of its record labels behind MiniDisc and still not succeed in taking over the world, AOL-TW can throw its huge content libraries behind broadband services and the like and still not succeed. But, if AOL-TW tries to do that --and everything indicates that they will-- they have the clout/cash to make broadband affordable enough for the end consumer to sell their content on. But that doesn't mean that someone else (Sony?) will not be able to sell different content on the same infrastructure/network (actually the DoJ will probably guarantee that they will).
All in all, I think the TW take-over (call it like it is) is a good thing. Now, if AT&T took over T-W, that would be another can of worms...
engineers never lie; we just approximate the truth.
I seem to recall from the Atlanta Linux Showcase that VA plans to patent their system for BIOS-level administration of Linux clusters --a hardware/software solution, with the software being GPL'ed IIRC.
This is my spotty recollection, but I cann't think of any other field where a hardware OEM like VA *can* innovate anyways...
engineers never lie; we just approximate the truth.
Of course the problem with meta^2 and above is that you have to group the content by well... content --my Greek-Turkish weblog has nothing to do with Slashdot although it uses a port of the Slash code.
engineers never lie; we just approximate the truth.
But isn't that what Open Source is about? Some additions to the Slash code may fix/. bugs --some maybe additions that don't interest the/. folk, but there are plenty of sites that can use/need a/.-like format and would love to add them --like mine, based on PHPSlash --a PHP port of Slash.
I haven't changed PHPSlash significantly yet, but when I do, I will surely roll back my changes to the CVS --that's what open source is about: a few hobbyists joining forces to produce something better than what they can by going at it alone. This is what this forum has been preaching all along, yet its own engine is closed source.
If the/. overlords are so short-sighted as to be afraid of releasing Slash, why are they preaching Open Source to begin with? Let me tell you: I've been running a/.-like site (on a totally different subject BTW) for 2 months now, and I can tell you that the back end has nothing to do with how popular a site is. Content, word-of-mouth, links, willingness of people to come out and post comments (where I am failing right now BTW) are vastly more important.
Technology is not the end-all-be-all. Technology (i.e. code) is a tool, a means to an end. The end is service, entertainment, ideas, what have you. Not some KBs of Perl code.
engineers never lie; we just approximate the truth.
I gave up on waiting for a Slash release. I was looking for a similar/.-like engine for my site, and after some research I settled on PHPSlash. It's at least a generation behind/. --no user accts, no dynamic homepages, no moderation-- but: a) it's Open Source, with a decent enough following, b) it's based on PHP, which I wanted to learn.
FYI, there's also Squishdot (sorry no link in my RAM;-) based on Zope and a coupla interesting projects on the Java Apache pages.
I agree with the other comments though. The/. overlords should be releasing Slash, even as a rough draft, just so to put their code where their mouths are.
engineers never lie; we just approximate the truth.
Re:Be a spartan? No way!
on
Gates of Fire
·
· Score: 3
Well, yeah Sparta wasn't a happy place to live back in those days, and if you visit the actual city (I am Greek, BTW) you will see why --it's locked in by high mountains all around; it just looks gloomy;-)
At any rate, you're right on all points --modern Greek history books estimate the Persian army to have been closer to ~300-500k rather than 2M. Also, look at what the poor Persians were carrying --cotton uniforms with wick shields and spears-- and their training --they had the draft; most of the army was peasants and farmers, only Xerxes' personal guard were professional soldiers. They went against highly trained warriors (male Spartan citizens, who were the only eligible to fight for Sparta were training for war as a full-time job) clad in brass armor, brass shields, spears and swords.
That's why it took 500:1 to get past Thermopylae --and then it took treason (another curious trivia: the name of the traitor "Ephialtes" has passed on to modern Greek language as "nightmare"/"supreme traitor").
Plus you have to consider the Spartan motivation: male Spartans grew up training for war; and when they went into battle their mothers gave them their shields (carrying the family insignia) with this wish: "bring it back or be carried on it [i.e. die]".
engineers never lie; we just approximate the truth.
Being a Greek, it was a nice surprise seing this story on Slashdot. The battle of Thermopylae is one of our favorite historical moments as a nation. These days Thermopylae is just another spot on the highway, but if you take the time to visit the monument there, you'll see on the most gut-wrenching epitaphs I know about on the ancient memorial there: "Stranger, tell the Spartans that we lie here, having followed their rules".
Also, I'd like to correct one common fallacy: there weren't just 300 Spartans at Thermopylae: they also had another 700 (I think) allies from Thebes. Still, the odds were like 500:1 --consider that military science says you only need 6:1 to take a well-defended position...
And at the end they only lost due to treason --a local shepherd who the Persians bribed, guided some Persian soldiers through the rough paths of the area around the Spartan stronghold, surrounding them...
Spartan society was one of the strictest, most autocratic of ancient times, but noone can claim they had no valor...
engineers never lie; we just approximate the truth.
In case anybody is wondering, it's been done: my company does this and so do others.
For example, today's deal between Oracle and Boeing for a business-to-business portal on aircraft parts (an industry that definetely needs info infrastructure) is an example of how middlemen are becoming more prevalent on the Web --just thinner and smarter.
Actually, if you think about it, the Web has added more levels of middlemen than the "real world" has ever needed. I mean, we're here discussing an article on a site that provides links to other sites that provide news. And as the Web grows, we'll probably need more middlemen... The big difference is that the end consumer actually loses less to the middleman (or in the case of say buy.com, nothing at all).
engineers never lie; we just approximate the truth.
Slashdot Mirror
...this will mean that Unix as a whole will move up in the enterprise as an alternative to W2K, Novell, etc.
;-)...
Plus, more interestingly, it will put the pressure to Linux to become better. For one thing, NT was too easy a target
engineers never lie; we just approximate the truth.
I am all for it; where does one start? ;-)...
engineers never lie; we just approximate the truth.
OK, fine; really, the format here is almost beside the point. I am sure that whatever group gets to decide on the format will be knowledgable enough to decide on something practical and readable for both machines and humans.
/. for that matter) agree that it is about time to move to a standardized format, and b) that this migration is as painless as possible. Let's agree on that, and get a momentum behind this. The engineering details warrant a larger audience and a much longer discussion...
The more important thing here, is that: a) the community (not necessarily us, this thread, or
engineers never lie; we just approximate the truth.
No, I wasn't; but please, read a few lines further: I wasn't suggesting that config files should be locked out --just that /etc and /var should be locked out while we migrate to /conf (or whatever it gets to be called). /conf and its config files (the standardized config files) would and should be editable by the user.
/conf should be more like AIX's config files, or sorta like /proc: real text files, but changes in them should be detectable by some backward-compatibility deamon, that would parse the new file and write an old-format /etc or /var file. As more and more programs migrate to the new standardized format, the need for still having /etc and /var around will die of. Sorta like the .ini -> registry migration in Windows. But without the Windows stupidity of making the registry uneditable and unreadable by a human --or, for that matter, uneditable w/o a specialized tool.
But as someone else suggested in this thread,
With careful engineering and everybody pulling together (which, with the added benefits of a standard format to users and developers alike won't be too hard, IMHO), we could have a clean, standardized system in 2-3 years easily...
engineers never lie; we just approximate the truth.
So, as I said above, what about Apache's format? XML-ish enough and more human-readable...
engineers never lie; we just approximate the truth.
Yes, XML is ugly and not as effient as those #s and ;s... but: XML is already agreed upon and "out there"; there is no need to come up with Yet Another Standard. More importantly, XML's "loose" enough to cover every configuration file need _I_ can think of (not that that's saying much, BTW ;-)...
.conf syntax is XMLish enough, IMHO: it's parsable, human-readable and -editable. And your argument that text editors are mature and we should stick to text applies both ways: modern editors (emacs, vim) are mature enough to handle a text-based, XML-like language with little added user work. Added benefit: since everything will be standardized and immediately parsable, you could probably click/Ctrl-] on a config parameter and get that man file entry you want... vim can be made to do it now...
;-)...
E.g.: Apache's
We can do XML-based config files now, with existing tools, without departing too much from the "Unix way". I think it's time we should. Think about it: before Bill Joy, unix admins probably thought one line of text at a time was all _they_ needed
engineers never lie; we just approximate the truth.
My $0.002: forget
As for the format; yeah, it will be tough to iron out, but so was POSIX. I ain't that level of hacker, but I do think that XML should be able to handle everything that a program would need. After all, XML is more of a syntax than a language, right? The added benefits:
As I said before, a GUI layer on top will be almost trivial, and expandable to no end.
There could be a standard configuration-reading library, that any utils developer can use to parse his or her config file, saving that stupid work... (I've always hated writing parsers, don't you? ;-)
engineers never lie; we just approximate the truth.
I'll go one step further: we don't just need more feedback from admintools (actually, I agree with the two-layer approach: a high-level, newbie layer and a lower-level, expert layer of feedback): we need bette configuration files. There was an idea being thrown around in a previous /. discussion for standardizing on an XML-derived config syntax. Now, wouldn't that be nice? Standardized config-files with parsable comments... a GUI layer would be only a parser away.
engineers never lie; we just approximate the truth.
Why is a GUI a bad thing? I totally disagree with you that the GUI and the need to things the 'pretty' way is what makes Windows unstable. What makes Windows unstable is that it is a huge engineering effort, accomplished by one company and closed to outside scrutiny. It's like Ford kept developing cars with the hoods shut off and explossives triggered to the hood ;-)...
;s and ugly Unix-y text files. I've been administering/using Unix boxes for a decade now: I am sick, sick and tired of all the different little syntaxes and quirks thrown into every configuration file (Sendmail is the champion of quirkiness, of course).
:-(...
GUIs are good. Humans primarily rely on visual information, not a buncha #s and
Stop the madness! You can/should/have to standardize... even win16 had a consistent *.ini file syntax that made sense even if you had never seen the application before. Why can't Unix standardize? why not Linux? not only it will help admins, it will make the creation of a GUI layer on top, much, much easier. As things are now, every utility needs a parser to make sense out of its config file...
Better stop ranting now... I am going back to my POS 98 laptop, fondly remembering the days when a reliable, pretty, configurable Unix still existed: it was called NeXTStep
engineers never lie; we just approximate the truth.
Yeajh, but DVD's can be much, much cheaper than VHS tapes, so there wouldn't be an inventory issue; you wouldn't return the disks so that the store had enough to give out, but just to recycle them. Plus, in that scheme, with a decent return rate, you could probably charge $2-$3 a disk...
;-)...
The medium becomes practically free, the cost to keep tracks of them dwindles down --no need for bar-scanners, minimum-wage-paid attendands, DBs of customer data...
But those advantages exist in this idea as well... Hell, why even have a store? put them into a vending machine and you're done. This can kill Blockbuster
It's that damn non-degradable plastic that sucks...
engineers never lie; we just approximate the truth.
Now, if they could figure a way to turn the coating back to transparency with some special laser, so landfills don't get crammed up with this suckers, I'd be all for it.
Think about it... you could be sitting at the checkout line in a grocery store, see a movie you missed and buy it for $3-4 without worrying about special players, returning times, and all that crap...
engineers never lie; we just approximate the truth.
I too have to give my props to HP LaserJets. An amusing anecdote back from the days when computer support paid my college tuition:
:-). So, we print a test-page on both. One had printed ~1,200,000 (that's 1.2 MILLION pages) and the other ~700,000... After playing with the screws and the covers, we open one up. The motherboard was literally under a 1/2" blanket of dust. I mean solid dust that came off like a piece of cloth. We cleaned those guys up, and as far as I know they were still chugging along after I graduated ;-)...
My college at the time had several high-end HP LJ III (x?). Their expected engine life-time (I guess MTBF) was ~250,000 pages. So, one day, my supervisor comes by and he wants to open two of them up and clean the dust out (no instructions for that, BTW
After that I always recommend an HP...
engineers never lie; we just approximate the truth.
Since it's a greek word --actually a word-stem, I can guarantee you is prounounced met-a (and in Greek, actually met-A).
engineers never lie; we just approximate the truth.
Probably one of the few truely great ideas in the Web development industry. It means freedom from client peculiarities --forget about all writing for all those different browsers again and again, just one huge translator template will (e.g. XML->Opera-compatible HTML, or IE-compatible HTML or AvantGO, etc). It means that potentially the same server can be serving not only PCs, laptops, PDAs and the like, but also other software, by reading plain XML, or some subset of it.
;-)...
In the OSS arena, the best example of XML on the server=>HTML (or for that matter anything else) on the client is Cocoon. I played around with Cocoon 1.x a little bit and it's very impressive architecturally, but even the principals agree that the performance isn't there yet. I am eagerly awaiting for Coccoon 2 though
engineers never lie; we just approximate the truth.
I will repeat this until I am soar, 'coz, well, it's a soar point with us in the Beowulf community: Linux SMP sucks. If you want good SMP performance, you're better of with NT or Solaris.
The big problem with Linux SMP, IMNSHO: NO CPU affinity. Which means roughly this: processes are rotated thru all available CPUs, instead of being assigned to one CPU and then being dynamically balanced (new jobs sent to the lightest-used CPU, when CPUs are imbalanced by some threshold %, move 1-2 smaller jobs that will balance them out).
What does this mean? well, CPU cache is practically useless. Makes all that dough spent on Xeons instead of Celerons seem wasted --and it is.
Don't get me wrong; I am all for Linux, and I am sure SMP will catch up pretty soon. But don't go spending $$$ on SMP machines expecting (n-1)*100% increase in performance.
engineers never lie; we just approximate the truth.
I could try, but then again you can find out from the horse's mouth...
engineers never lie; we just approximate the truth.
A ticker symbol is enough, IMNSHO... for one thing, consider all those people (I know a few myself) that sign for every IPO E*Trade or some other online broker offers in the hope they'll make money not from the company's value, but other traders' idiocy.
;-) (and that's exactly the point, isn't it?)
The market as it is now, especially the high-tech Internet market (never mind the Linux one) is one big Ponzi scheme. And as any Ponzi scheme its success or failure doesnt depend on economics but perception, in which case, a cute ticker symbol may be all you need.
LinuxOne isn't even the worst one... eHow.com (or was it HowTo.com or How2.com?) filed for an IPO selling themselves as a portal while their revenue came from rebate processing offline. And then there was that ISP (eff-something or other) that had no revenue, no infrastructure, no clients, just some hot-shot big-name CEO, and they filed an S-1 claiming that they will use the proceeds to buy other, real ISPs... I just hope that this lunacy continues till I vest
engineers never lie; we just approximate the truth.
Hear, hear... Completely agreed. This is a merger of interests, a conglomerate not a monopoly in any means. I would put it this way: AOL is gonna be to the Internet what Sony is to consumer electronics: an infrastructure company that has the content to attract people to its services and technologies. Nothing more, nothing less.
And that's probably not a bad thing --in the same way that Sony can throw the wight of its record labels behind MiniDisc and still not succeed in taking over the world, AOL-TW can throw its huge content libraries behind broadband services and the like and still not succeed. But, if AOL-TW tries to do that --and everything indicates that they will-- they have the clout/cash to make broadband affordable enough for the end consumer to sell their content on. But that doesn't mean that someone else (Sony?) will not be able to sell different content on the same infrastructure/network (actually the DoJ will probably guarantee that they will).
All in all, I think the TW take-over (call it like it is) is a good thing. Now, if AT&T took over T-W, that would be another can of worms...
engineers never lie; we just approximate the truth.
I seem to recall from the Atlanta Linux Showcase that VA plans to patent their system for BIOS-level administration of Linux clusters --a hardware/software solution, with the software being GPL'ed IIRC.
This is my spotty recollection, but I cann't think of any other field where a hardware OEM like VA *can* innovate anyways...
engineers never lie; we just approximate the truth.
I think Dave Winer has already pulled off something akin to your idea --I couldn't find that meta-log, but there is this weblog monitor on his site and of course there is the weblog portal and there is a portal of weblog portals (meta^3 anybody?).
Of course the problem with meta^2 and above is that you have to group the content by well... content --my Greek-Turkish weblog has nothing to do with Slashdot although it uses a port of the Slash code.
engineers never lie; we just approximate the truth.
But isn't that what Open Source is about? Some additions to the Slash code may fix /. bugs --some maybe additions that don't interest the /. folk, but there are plenty of sites that can use/need a /.-like format and would love to add them --like mine, based on PHPSlash --a PHP port of Slash.
/. overlords are so short-sighted as to be afraid of releasing Slash, why are they preaching Open Source to begin with? Let me tell you: I've been running a /.-like site (on a totally different subject BTW) for 2 months now, and I can tell you that the back end has nothing to do with how popular a site is. Content, word-of-mouth, links, willingness of people to come out and post comments (where I am failing right now BTW) are vastly more important.
I haven't changed PHPSlash significantly yet, but when I do, I will surely roll back my changes to the CVS --that's what open source is about: a few hobbyists joining forces to produce something better than what they can by going at it alone. This is what this forum has been preaching all along, yet its own engine is closed source.
If the
Technology is not the end-all-be-all. Technology (i.e. code) is a tool, a means to an end. The end is service, entertainment, ideas, what have you. Not some KBs of Perl code.
engineers never lie; we just approximate the truth.
I gave up on waiting for a Slash release. I was looking for a similar /.-like engine for my site, and after some research I settled on PHPSlash. It's at least a generation behind /. --no user accts, no dynamic homepages, no moderation-- but: a) it's Open Source, with a decent enough following, b) it's based on PHP, which I wanted to learn.
;-) based on Zope and a coupla interesting projects on the Java Apache pages.
/. overlords should be releasing Slash, even as a rough draft, just so to put their code where their mouths are.
FYI, there's also Squishdot (sorry no link in my RAM
I agree with the other comments though. The
engineers never lie; we just approximate the truth.
Well, yeah Sparta wasn't a happy place to live back in those days, and if you visit the actual city (I am Greek, BTW) you will see why --it's locked in by high mountains all around; it just looks gloomy ;-)
At any rate, you're right on all points --modern Greek history books estimate the Persian army to have been closer to ~300-500k rather than 2M. Also, look at what the poor Persians were carrying --cotton uniforms with wick shields and spears-- and their training --they had the draft; most of the army was peasants and farmers, only Xerxes' personal guard were professional soldiers. They went against highly trained warriors (male Spartan citizens, who were the only eligible to fight for Sparta were training for war as a full-time job) clad in brass armor, brass shields, spears and swords.
That's why it took 500:1 to get past Thermopylae --and then it took treason (another curious trivia: the name of the traitor "Ephialtes" has passed on to modern Greek language as "nightmare"/"supreme traitor").
Plus you have to consider the Spartan motivation: male Spartans grew up training for war; and when they went into battle their mothers gave them their shields (carrying the family insignia) with this wish: "bring it back or be carried on it [i.e. die]".
engineers never lie; we just approximate the truth.
Being a Greek, it was a nice surprise seing this story on Slashdot. The battle of Thermopylae is one of our favorite historical moments as a nation. These days Thermopylae is just another spot on the highway, but if you take the time to visit the monument there, you'll see on the most gut-wrenching epitaphs I know about on the ancient memorial there: "Stranger, tell the Spartans that we lie here, having followed their rules".
Also, I'd like to correct one common fallacy: there weren't just 300 Spartans at Thermopylae: they also had another 700 (I think) allies from Thebes. Still, the odds were like 500:1 --consider that military science says you only need 6:1 to take a well-defended position...
And at the end they only lost due to treason --a local shepherd who the Persians bribed, guided some Persian soldiers through the rough paths of the area around the Spartan stronghold, surrounding them...
Spartan society was one of the strictest, most autocratic of ancient times, but noone can claim they had no valor...
engineers never lie; we just approximate the truth.
In case anybody is wondering, it's been done: my company does this and so do others.
For example, today's deal between Oracle and Boeing for a business-to-business portal on aircraft parts (an industry that definetely needs info infrastructure) is an example of how middlemen are becoming more prevalent on the Web --just thinner and smarter.
Actually, if you think about it, the Web has added more levels of middlemen than the "real world" has ever needed. I mean, we're here discussing an article on a site that provides links to other sites that provide news. And as the Web grows, we'll probably need more middlemen... The big difference is that the end consumer actually loses less to the middleman (or in the case of say buy.com, nothing at all).
engineers never lie; we just approximate the truth.