Erm, NO! I mean mutually INclusive: The set of people who skin and the set of people who program aren't necessarily mutually INclusive. Which was the assertion the poster was trying to make: that since these people are one in the same, skinning necessarily means taking time away from programming.
I think accessiblity is crucial (means using all your 'alts' and 'noframes' tags, etc.). Conformance to the browser/platform -neutral specs is probably important...which plays into accessibility.
And my own, personal wish, is some semblance of consistency among government pages. Have *every* page have a standard banner, department/agency emblem, and a link back to the main site. Standardize on this. Make links to parent agencies and departments which also have some standard bannar, or layout, so the poor citizen knows where, among the governmental hierarchy they are at any given point. Government is confusing enough without bad web navigation, etc. It almost warrants something like a governmental "web ring";)
Yeah, and what's gfm (Gnome File Manager) for then? They make it sound like Gnome was just in total useless disarray before the saintly Eazel came along, and that Eazel is essentially synonymous with the Gnome desktop. I mean, Gnome is a lot more than just one file manager/browser. Seems to me that Eazel is at best a peripheral player who is nicely writing some Free software for Gnome hoping to capitalize on it later. Hardly responsible for Gnome as a whole.
Um, the whole point of XUL was to have a cross-platform GUI. With that came "free" skinnability. People who skin and program aren't necessarily mutually inclusive! There are plenty of artsy graphics people who love to skin and show off their work, who haven't touched a line of code in their life. And there are plenty of programmers who will continue working hard on mozilla, and not spend their time working on skins. It's not like everybody on the Mozilla project has now decided "Hey guys, this skin stuff is really cool. Drop everything! Let's create skins instead!". And while skins may have the potential of creating confusing user interfaces, they also have the potential of creating much better, or customized ones. Instead of bitching over some programmer's brain-dead UI, you can make your own, or rely on some Really Smart UI or graphics guy to make one for you. If you don't like skins don't use them! That's why there is such a thing as "default" skin. Many people probably won't even change this skin, let alone realize that they can.
Does this mean that main memory and mass storage can now merge on the same medium? So essentially your filesystem IS your memory. The heap/stack/whatever is just located in some separate protected area. This would mean entirely redesigning the vast majority of operating systems which were designed to optimize the exact problem of memory/disk space usage, protection, etc. All of a sudden "disk cache", DMA, binary loaders, etc. are all history. Memory fragmentation and disk fragmentation are now the same thing. Anyway, sounds really cool. However, 256 MB mass storage is pretty damn small, and will be even orders of magnitude smaller 10 years from now. They better be able to ramp that number up.
As far as I know, the "flying saucer" toys from the 60s and 70s were just abysmal failures based on fans or hovercraft technology, that could barely scoot around. But the object in the post doesn't seem to have anything to do with props or hovercrafts...some other form of propulsion entirely.
And I don't see why the name of the business can't be given away...unless of course the poster is afraid of the men in black getting *him* too (which I guess isn't all that far fetched).
Yeah, my usual response to the "hey, we could make this 2% faster by just totally munging up the code!!" mentality, is that computing and software development these days is no longer about maximizing scarce resources, but in managing complexity. Resources are abundant, we're drowning in disk space, memory, data, etc. We should be writing software that solves *human* problems, not hardware problems. A stick of 128 MB RAM is a much better solution in many cases than 2 man-years of optimizing for hardware which will just be obsolete anyway. I'd rather have a solidly designed, well implemented system, which is easily maintainable and upgradable, than a system optimized to run like an amphetamine addict which will break in a year, once the hardware needs to be upgraded or a feature added.
...because XML is a *general* solution to describing structured data. For instance, the schema (DTD, whatever) may be tailored for document-type data, like XHTML, or perhaps to describe the structure of Real Life books. But we may also use XML to describe multimedia presentations, database structure, etc., etc. XML can describe pretty much anything under the sun, short of a few complicated things my poor brain probably couldn't understand, which you must use SGML for (XML being itself an application of SGML, eek!). So I see application-specific data formats going away. XML provides rules for describing the structure of any data you want. The point is to avoid niche, application-specific formats. Now, I don't know everything about LaTeX, but it seems to have a very specific application. Just because PDFs can be viewed pretty much everywhere, doesn't mean we should turn the web into PDF-land.
Well, Google at least caches sites. Why couldn't Slashdot simply link to the Google *cache*. If people wanted the fresh site, they could read the blaring text on top that said that it was a Google cache of the document you can reach by clicking on the following link. Then the issue is DOSing Google, but I think they can deal with it a bit better than old pizza-box or pototo server.
If you disregard that that last link is from a Christian site, I think you'll get the point that as, perhaps general violent crime is going down, we are seeing more and more, random, unpredictable, spontaneous and meaningless crime from young people. I read this as due to a deterioration of culture and tradition. No I'm not talking about a "moral crises" per se, and I'm not religious, but psychologically, a strong foundation of culture, tradition, acceptance, and an inherent place in the world are very important for the developing individual. Instead, our culture is the ultra-competitive capitalistic race, into which we bear children, slap their butts and yell "go!".
If I'm correct, we will start seeing these trends occur in more "developed" nations, shedding their traditions to embrace free market rat races (the two of which aren't necessarily mutually exclusive, although that's what seems to be happening in more developed countries).
First of all I will not write it in a native language, simply because unless I double as a security expert, that is way too dangerous, and hard to debug and maintain anyway.
I might write it in some scripting language, but hey, guess what?, Java is compiled down to bytecode, so unless that script is compiled down somehow, it's not going to be better than Java anyway. Add to that free garbage collecting, a built-in security policy system, and a wealth of quality implementations of almost every open standard you can think of, and Java is a very nice choice.
200k is what, 4 man years? Weigh that against the benefits of Java. Are you going to need 4 extra people dedicated to the task just to maintain this beast accross multiple architectures, operating systems, back-end systems, etc.? Java has proven itself quite up to the job of serving major web sites (I believe money.com is backended by servlets and java/corba).
As far as the interpreter being faster than the networks' abilities, you have to take in mind what most Linux developers do: they develop server software. In that case, your bandwidth is no longer the bottleneck, your processor is. If a language isn't sufficiently efficient, you'll be wasting a *lot* of hardware just to serve up a web site.
As far as end users are concerned, Java is Fast Enough(tm), but as far as most developers in the world are concerned, the ones who write real software, not the nice little shareware text editor, Java just doesn't cut the mustard when it comes to performance.
Ok, I call "bullshit". There is a point past which your bottleneck isn't bandwith OR processor. The bottleneck is *complexity*. I think Moore's law has pretty much brought us to the point that most of software development is not resource optimization, but simply complexity management. And Java, by providing rich cross-platform implementations of open standards, and good error handling, excels at this. You can always throw money at performance problems. The *real* problem is how to write quality software without it breaking in subtle and not-so-subtle ways, reducing maintainence and debugging, etc., and these were the *exact* goals the originators of Java had in mind when they designed it.
As for serving up a web site, servlets and JSP are compiled down to bytecode, and unless your perl or PHP script has been compiled down, that Java bytecode is going to run *plenty* fast.
The only performance problem I see, is on the client, and that is getting better every day, especially with the coming trend of dynamic translation/execution we are seeing.
Hate to sound snobby, but being able to read a software manual should be a job requirement if you use any software. Then again, many never care to figure out how to program their VCR, let alone solve the blinking 12.
Every tool has a use, and so does the Java environment. In fact, I think Java is one of the most flexible and useful languages/environments. It is a blessing on the server side where the bottleneck isn't really CPU, but simply handling the vast complexity of really large systems running on different hardware, across a network, doing all sorts of tasks, but having to coordinate with each other. Java is great for the server side: CORBA, RMI, servlets, JSP, JNDI, LDAP, messaging, JDBC database access, on and on. Rich APIs and standards compliance are provided for all of these. We can develop on our NT boxes, test on NT servers and low-end Unix boxes, then move over to the heaving duty Unix boxes, with zero code change. But Java is also pretty good, and getting better, on the client side, with a rich cross-platform widget and component toolkit, and better virtual machines. It allows us to create one client for our services, and deploy them accross PCs, Macs, and Unixes. Sure there's work to be done on making Java transparent on the client side...but we are already seeing a move toward dynamic translation/execution, with the Crusoe chip and other's like it, with IBM's DAISY, etc. I think we will see more integrated support for dynamic translation/execution in operating systems (e.g., Windows and OS X already do this to some extent with their legacy APIs and libraries) I think Java on the client is going to get even better.
As for the Java license, I think Sun just wants to keep control over their baby while it's still in the crucible. Java is still a very young language, and there are already several initiatives to make slightly different flavors out of it. For a proprietary company, Sun sure provides a hell of a lot for free: open specs, source code, tons of documentation, tons of free high quality libraries, packages, VMs, etc. Even though I consider myself more in the RMS than ESR camp, I'd have to say that I'm pretty satisfied with the management of Java. Even though it's not open source, it is so open that if Sun disappeared tomorrow, nothing would stop people from reimplementing and reusing the Java environment from the open specs, and source that is already written out there.
Erm, NO! I mean mutually INclusive: The set of people who skin and the set of people who program aren't necessarily mutually INclusive. Which was the assertion the poster was trying to make: that since these people are one in the same, skinning necessarily means taking time away from programming.
"Yep. You do."
I know you are but what am...oh nevermind.
I think accessiblity is crucial (means using all your 'alts' and 'noframes' tags, etc.). Conformance to the browser/platform -neutral specs is probably important...which plays into accessibility. And my own, personal wish, is some semblance of consistency among government pages. Have *every* page have a standard banner, department/agency emblem, and a link back to the main site. Standardize on this. Make links to parent agencies and departments which also have some standard bannar, or layout, so the poor citizen knows where, among the governmental hierarchy they are at any given point. Government is confusing enough without bad web navigation, etc. It almost warrants something like a governmental "web ring" ;)
"spear wielding, hide wearing native"
As if that were a bad thing...
After which the article immediately notes:
"(Gates is well aware of the irony--the old command line, left for dead, is back!)"
I believe it's "Sweet creeping zombie Jesus!" - The Professor, Futurama
Yeah, and what's gfm (Gnome File Manager) for then? They make it sound like Gnome was just in total useless disarray before the saintly Eazel came along, and that Eazel is essentially synonymous with the Gnome desktop. I mean, Gnome is a lot more than just one file manager/browser. Seems to me that Eazel is at best a peripheral player who is nicely writing some Free software for Gnome hoping to capitalize on it later. Hardly responsible for Gnome as a whole.
Um, the whole point of XUL was to have a cross-platform GUI. With that came "free" skinnability. People who skin and program aren't necessarily mutually inclusive! There are plenty of artsy graphics people who love to skin and show off their work, who haven't touched a line of code in their life. And there are plenty of programmers who will continue working hard on mozilla, and not spend their time working on skins. It's not like everybody on the Mozilla project has now decided "Hey guys, this skin stuff is really cool. Drop everything! Let's create skins instead!". And while skins may have the potential of creating confusing user interfaces, they also have the potential of creating much better, or customized ones. Instead of bitching over some programmer's brain-dead UI, you can make your own, or rely on some Really Smart UI or graphics guy to make one for you. If you don't like skins don't use them! That's why there is such a thing as "default" skin. Many people probably won't even change this skin, let alone realize that they can.
Does this mean that main memory and mass storage can now merge on the same medium? So essentially your filesystem IS your memory. The heap/stack/whatever is just located in some separate protected area. This would mean entirely redesigning the vast majority of operating systems which were designed to optimize the exact problem of memory/disk space usage, protection, etc. All of a sudden "disk cache", DMA, binary loaders, etc. are all history. Memory fragmentation and disk fragmentation are now the same thing. Anyway, sounds really cool. However, 256 MB mass storage is pretty damn small, and will be even orders of magnitude smaller 10 years from now. They better be able to ramp that number up.
As far as I know, the "flying saucer" toys from the 60s and 70s were just abysmal failures based on fans or hovercraft technology, that could barely scoot around. But the object in the post doesn't seem to have anything to do with props or hovercrafts...some other form of propulsion entirely.
And I don't see why the name of the business can't be given away...unless of course the poster is afraid of the men in black getting *him* too (which I guess isn't all that far fetched).
So when will they be coming out with hexidecimal touchtone phones?
"Family Steakhouse: phone DEADBEEF for reservations."
Thank you for playing "You have just been trolled"
Yeah, my usual response to the "hey, we could make this 2% faster by just totally munging up the code!!" mentality, is that computing and software development these days is no longer about maximizing scarce resources, but in managing complexity. Resources are abundant, we're drowning in disk space, memory, data, etc. We should be writing software that solves *human* problems, not hardware problems. A stick of 128 MB RAM is a much better solution in many cases than 2 man-years of optimizing for hardware which will just be obsolete anyway. I'd rather have a solidly designed, well implemented system, which is easily maintainable and upgradable, than a system optimized to run like an amphetamine addict which will break in a year, once the hardware needs to be upgraded or a feature added.
You are just responding to a troll which posted the same exact message last time HURD came up.
Maybe a drunk squirrel?
There is also a pretty funny picture of a squirrel lounging with a bottle of beer and a cigarrette floating around the web somewhere.
...because XML is a *general* solution to describing structured data. For instance, the schema (DTD, whatever) may be tailored for document-type data, like XHTML, or perhaps to describe the structure of Real Life books. But we may also use XML to describe multimedia presentations, database structure, etc., etc. XML can describe pretty much anything under the sun, short of a few complicated things my poor brain probably couldn't understand, which you must use SGML for (XML being itself an application of SGML, eek!). So I see application-specific data formats going away. XML provides rules for describing the structure of any data you want. The point is to avoid niche, application-specific formats. Now, I don't know everything about LaTeX, but it seems to have a very specific application. Just because PDFs can be viewed pretty much everywhere, doesn't mean we should turn the web into PDF-land.
Well, Google at least caches sites. Why couldn't Slashdot simply link to the Google *cache*. If people wanted the fresh site, they could read the blaring text on top that said that it was a Google cache of the document you can reach by clicking on the following link. Then the issue is DOSing Google, but I think they can deal with it a bit better than old pizza-box or pototo server.
The Filthy Critic only gave it 2 fingers:
http://www.bigempire.com/filthy/
I hope Slashdot doesn't think "nostalgic geeky comic book movie" == "unreproachably Good".
What about PicoBSD?
http://www.cnn.com/WORLD/9706/07/japan.beheading/i ndex.html
http://www.cnn.com/WORLD/9803/14/japan.teen.violen ce/
1 ,6 474,00.html
e ec h.html
http://eyeball.asia1.com.sg/Eyeball/Story/1,138
http://www.gospelcom.net/pof/kpof/inside/freesp
If you disregard that that last link is from a Christian site, I think you'll get the point that as, perhaps general violent crime is going down, we are seeing more and more, random, unpredictable, spontaneous and meaningless crime from young people. I read this as due to a deterioration of culture and tradition. No I'm not talking about a "moral crises" per se, and I'm not religious, but psychologically, a strong foundation of culture, tradition, acceptance, and an inherent place in the world are very important for the developing individual. Instead, our culture is the ultra-competitive capitalistic race, into which we bear children, slap their butts and yell "go!".
If I'm correct, we will start seeing these trends occur in more "developed" nations, shedding their traditions to embrace free market rat races (the two of which aren't necessarily mutually exclusive, although that's what seems to be happening in more developed countries).
First of all I will not write it in a native language, simply because unless I double as a security expert, that is way too dangerous, and hard to debug and maintain anyway.
I might write it in some scripting language, but hey, guess what?, Java is compiled down to bytecode, so unless that script is compiled down somehow, it's not going to be better than Java anyway. Add to that free garbage collecting, a built-in security policy system, and a wealth of quality implementations of almost every open standard you can think of, and Java is a very nice choice.
200k is what, 4 man years? Weigh that against the benefits of Java. Are you going to need 4 extra people dedicated to the task just to maintain this beast accross multiple architectures, operating systems, back-end systems, etc.? Java has proven itself quite up to the job of serving major web sites (I believe money.com is backended by servlets and java/corba).
As far as the interpreter being faster than the networks' abilities, you have to take in mind what most Linux developers do: they develop server software. In that case, your bandwidth is no longer the bottleneck, your processor is. If a language isn't sufficiently efficient, you'll be wasting a *lot* of hardware just to serve up a web site.
As far as end users are concerned, Java is Fast Enough(tm), but as far as most developers in the world are concerned, the ones who write real software, not the nice little shareware text editor, Java just doesn't cut the mustard when it comes to performance.
Ok, I call "bullshit". There is a point past which your bottleneck isn't bandwith OR processor. The bottleneck is *complexity*. I think Moore's law has pretty much brought us to the point that most of software development is not resource optimization, but simply complexity management. And Java, by providing rich cross-platform implementations of open standards, and good error handling, excels at this. You can always throw money at performance problems. The *real* problem is how to write quality software without it breaking in subtle and not-so-subtle ways, reducing maintainence and debugging, etc., and these were the *exact* goals the originators of Java had in mind when they designed it.
As for serving up a web site, servlets and JSP are compiled down to bytecode, and unless your perl or PHP script has been compiled down, that Java bytecode is going to run *plenty* fast.
The only performance problem I see, is on the client, and that is getting better every day, especially with the coming trend of dynamic translation/execution we are seeing.
Hate to sound snobby, but being able to read a software manual should be a job requirement if you use any software. Then again, many never care to figure out how to program their VCR, let alone solve the blinking 12.
Every tool has a use, and so does the Java environment. In fact, I think Java is one of the most flexible and useful languages/environments. It is a blessing on the server side where the bottleneck isn't really CPU, but simply handling the vast complexity of really large systems running on different hardware, across a network, doing all sorts of tasks, but having to coordinate with each other. Java is great for the server side: CORBA, RMI, servlets, JSP, JNDI, LDAP, messaging, JDBC database access, on and on. Rich APIs and standards compliance are provided for all of these. We can develop on our NT boxes, test on NT servers and low-end Unix boxes, then move over to the heaving duty Unix boxes, with zero code change. But Java is also pretty good, and getting better, on the client side, with a rich cross-platform widget and component toolkit, and better virtual machines. It allows us to create one client for our services, and deploy them accross PCs, Macs, and Unixes. Sure there's work to be done on making Java transparent on the client side...but we are already seeing a move toward dynamic translation/execution, with the Crusoe chip and other's like it, with IBM's DAISY, etc. I think we will see more integrated support for dynamic translation/execution in operating systems (e.g., Windows and OS X already do this to some extent with their legacy APIs and libraries) I think Java on the client is going to get even better.
As for the Java license, I think Sun just wants to keep control over their baby while it's still in the crucible. Java is still a very young language, and there are already several initiatives to make slightly different flavors out of it. For a proprietary company, Sun sure provides a hell of a lot for free: open specs, source code, tons of documentation, tons of free high quality libraries, packages, VMs, etc. Even though I consider myself more in the RMS than ESR camp, I'd have to say that I'm pretty satisfied with the management of Java. Even though it's not open source, it is so open that if Sun disappeared tomorrow, nothing would stop people from reimplementing and reusing the Java environment from the open specs, and source that is already written out there.