They're using subdermal chips on animals now -- basically, the guts of a smartcard yanked out and put in an ear or something. Cheaper, easier, and can be handled in an automated manner, unlike brands or tattoos.
And maybe someday people will get this. Of course, at first it will be a convenience, like the first credit cards, and become more and more inconvenient not to have...
The problem is that for centuries, US workers have been *massively* more wealthy than third world workers. You bitch about CEOs having 500 times your salary? How about the workers that *you* are making 500 times more than?
You know how big companies can squash little ones? It isn't necessarily because they're that much more efficient (ever seen overhead at a large company? Stupid decisions, overpriced purchases...) It's because large companies can exploit workers in other nations.
And it isn't just multinationals. We yank oil out of other countries at ridiculously low prices so that we can fuel our good transport system, massively cutting the costs of our centralized production. We make products overseas at brutally low wages and then bring them here. A medium-sized company can pay an import company and get their piece of the overseas profit.
So people on here are bitching about how "the American worker *deserves* more". Don't make me laugh. You're living large off the fruits of other countries, friends. Your complaint is that you don't have the latest model car, or a fucking high-definition TV? The people that your comforts are coming from have issues like *starving*.
Now, if you want to take a much more mercenary approach, like "screw workers in other countries and execs, I'm looking out for #1", that's reasonable. But the moral arguments that are coming up here are laughable. "The CEO makes more money than I do, which is unfair". Christ.
That's a facinating thought. Sure, replacing engineers with an offshore worker saves money...I wonder how hard it is to H1B executives as well? Wouldn't that save...more money per visa, which is a constant cost to the company?
Seems like H1Bs should be aimed at execs, since each visa can save the company more money. Aiming them at engineers is a misuse of company funds.
"integration" is a very negative thing from an engineering standpoint -- modularity is almost always better. There's no reason in the least that "integration" implies fast start times, which can be achieved without the mingling of web browser code and the OS that MS did.
People want UI consistency. That's reasonable. That does not imply integration of the guts.
People want good performance. That's also reasonable, and also does not imply integration of the guts (which often makes it more difficult to profile programs and results in reduced performance).
If you want to have a daemon running that kepps your web browser's core bits in memory, or use a RAM disk for it, or not read eight zillion config files at start up, or have your OS use a less retarded dynamic loading mechanism, that's fine. None of that implies integration.
Mozilla is not a good example of an app free of integration -- it itself has about four applications all jumbled together in its guts. Phoenix qualifies, but unfortunately has a huge amount of baggage from Mozilla.
So what you *really* mean is that you don't like Mozilla's shoddy performance and prefer IE, *not* that you "like integration".
An example of modularity -- where each component of a system provides certain services, and if B relies on service A provided by module A1, I can replace A1 with A2 and B will keep working.
*This* is what you nearly always want, not "integration" where A and B become mingled.
I read through a study on this -- economic costs of smoking.
Yes, there are more healthcare costs, but the lifespan expectancy drastically shortens, so smokers are less likely to recieve the benefits of Social Security. Furthermore, when the taxes that smokers pay that go to everyone are factored in, the researchers concluded that smokers actually are an economic benefit to non-smokers (of course, they certainly could have missed some factors).
The total economic benefit of someone smoking a pack of cigarettes to the non-smoking community was estimated to be something like ten cents, IIRC.
The overwhelming factor is that smokers tend to die early, and never enjoy their retirement.
If anyone's still dumb enough to be smoking, that study should have put them off...
I have a PS/2 keyboard, as do 99% of PC users. I use a PS/2 mouse, which is getting a little less common, but *hardly* unheard of (esp. since Logitech makes PS/2-and-USB compatibile mice).
2.2 would work quite fine for a server.
Re:Judging from the trailer
on
Equilibrium
·
· Score: 2
I dunno. The description sounds good. I *hate* wire work...:-)
No, "Windows" is a generic term used for a particular element of a GUI. It's not a generic term for an operating system as a whole.
Also, trademark law is built mostly to prevent companies from profiting by consumer confusion. There's a pretty strong argument (see my first post) that that's what the Lindows people were trying to do. So, yes, I don't think that "Lindows" is a reasonable choice on the part of the Lindows people.
Because company A is large and not making idle threats about suing, and company B's costs in changing their name may be less than paying for defending against the lawsuit (which they might end up losing, anyway).
The GTK/GTNOME people did it at first, but there's so much GNOME software now that it's pretty much abandoned -- essentially no new software starts with a g.
The KDE folks are still guilty. It makes the product names sound *dumb*, not "integrated" or whatever they're trying.
It's kind of ugly for everyone involved. "window" is definitely a generic term for a windowing interface. When MS chose the term "Microsoft Windows", they sure as hell weren't thinking of trademark issues.
The problem is that then Lindows came out. Now, "Lindows" isn't just a windowing system -- it's an operating system, rather similar to what MS is selling. Furthermore, Wal-Mart sells these damn little boxes to people who have little computer experience and say that they have "Lindows" and are "Windows compatible". There's a pretty good case for confusion there if you have an inexperienced buyer. I don't have a lot of sympathy for the Lindows people -- I think it's fair to claim that they were trying to take advantage of confusion.
So MS sues them. Probably the only justified legal move MS has made in the last decade. The judge not *only* denies the injunction, but states that "Windows" is/has become a generic term. So now Microsoft is panicking and trying to do damage control to regain control of their product name. They go after everyone using Windows to try to build up a stronger case for future trademark infringement suits. There's nothing MS would hate more than ten companies out of China selling WINE+Linux+GNOME systems called "Super Windows".
Frankly, this whole thing wouldn't have happened if the Lindows people hadn't pulled their attempt to grab a little MS market share...
Microsoft chose to call their product "Microsoft Windows" in an attempt to get product-company association. That's fine, but they forego the ability to attack people making products called "Remote Windows" or "CacheWindows".
Oh, they'll probably make some stupid case about how the thing is close enough to cause confusion, but I have a hard time seeing a judge buying it.
I'd say it's pretty notable. Apple's never been noted for particularly buggy code, though OS X has had a fairly nasty number of things like kernel oopses since its introduction. So while it's not *that* out of line for issues to pop up in a youthful OS, the amazing thing is that this didn't show up before./me thinks Apple would have been better using someone else's kernel -- like the FreeBSD one -- verbatim instead of trying to hack up that Mach POS (which I've heard nothing but bad things about from OS people up at Carnegie Mellon, where Mach was developed). They could still have plopped Carbon and Quartz and all their other goodies on top.
Of course, I certainly could be missing something -- could be that the FBSD kernel just didn't do something that Apple had to have it do, and that the FBSD people wouldn't have accepted. Could be SMP issues, I suppose...
It was broken, but I found it via google. Okay, fine. What I assume the relevant information is at the site is Despite using Java, we have achieved performance that rivals (and sometimes exceeds) that of C/C++. The point of his paper was that the particular architecture he was using, *even though* implemented in Java, performed better than Apache and some other webserver called Flash that I haven't heard of. It's comparing architecture 1 in Java versus architecture 2 in C. If he wants to build an architecture 1 server in C, there might be more grounds for comparison. Apache certainly does not represent a performance cap on C -- there are many webservers written in C that outperform Apache -- Boa and Tux are two off the top of my head, though I'm sure I could find more if I went looking.
I thought you wanted to trade features and convenience for speed. Or is it some features and convenience.
Oh, I want to be able to code in the thing, sure. It's quite feasible to code large scale software projects in C, as has been demonstrated many times. It simply isn't feasible to do the same in assembly (granted, there has been some work on oddities like typed assembly language, but they're nothing more than research projects, and I doubt they'll ever add up to much.). I want a language that places a few constraints on the software author to improve the optimizer. Ocaml is a good example that good speed and functionality can be had together -- now, the only thing that needs to be done is produce a popular, imperative language that has good performance. (Not all of us are functional language fans.)
I don't think I was talking about the language specs at that point. Rather implementations.
Okay, fine. Blackdown Java doesn't use pthreads. It also eats more memory (and, incidently, runs more slowly than IBM's JVM, which does use pthreads.)
And it certainly is possible to write Java progs which scale better than equivalent C programs. On the same hardware. It has been done.
I can write a bublesort in C and a quicksort in Java or visa versa. My beef is that the Java language puts fundamental caps on performance that I think are unwarranted and unnecessary, regardless of whether the language is "modern" or not.
Okay, gets() has been judged to have risks higher than the worthwhile benefits, and has been obsoleted. GCC at least will issue a warning when you use it. There are certainly times when using gets() could be justified -- if, for instance, I have a program that uses IPC through stdin, so I have guarantees on the length of the buffer -- the code on each end is trusted. This way, I don't have to check lengths. However, there's no requrement to use gets() if it's not appropriate for your situation (i.e. reading in data from the user), since fgets() exists and works just fine.
Just to give you some perspective, I was arguing about language performance some time ago on Slashdot and someone mentioned that IBM had added or was considering adding an option to disable bounds checking on arrays precisely because of the performance hit. People *care* about the peformance involved in bounds-checking everything. If you're using the appropriate API call for the appropriate situation, there's no problem.
This is relevant to our discussion, since you wrote speed is almost everything in a language...if you trade those goals in a language design for speed, you would very unlikely find fixing these issues in the future easy. While performance issues can be dealt in the implementation far easier than breaking languages.
I said that functionality could be added later -- performance limitations stuck with developers forever. You said that functionality should be added soon and performance worried about later. I responded and said that this *had* happend via libraries like glib for C. You complained that functionality was being added to libraries, rather than (technically) to the language. I said that it was an issue of semantics -- that whether the improvements added keywords or functions didn't matter, as long as they added the needed functionality. I still stand by that, and I don't see how what you wrote here is a rebuttal to that.
Maybe not order, maybe just one order.
I'm very dubious that you could even manage one order. Perhaps there's a case somewhere that could do this, but in general, even a few years back when compilers were much less good, recoding inner loops was unlikely to buy you anything like this. As I pointed out, Rasterman was unable to improve on current gcc code.
The point is, these are all trade offs, Java and Erlang are higher-level languages than both C and assembly, and raw speed is definitely a trade-off for convenience, portability, etc., etc.
I disagree that raw speed must be traded to achieve convenience. I'm not a huge fan of ocaml the language, but ocaml code is extremely portable, runs nearly as fast as C, and is a very high-level language. Both speed and modernity can be achieved.
C compilers could get significantly better optimization (and add better checking and modern features) if an additional series of constraints were laid on top of the very free-form C. There are a few languages that do this sort of thing now. Splint, for instance (a lint for C that can handle extra constraints on C), can do this a little. I've seen more involved ones, though I don't have names handy.
Slashdot Mirror
You go look at your annoying Flash sites and the rest of us will enjoy a readable website.
He just gave you a free dollop of information, and you're bitching about his presentation? I mean, STFU already.
consistantly
Taco's Law: Anyone criticizing a spelling or grammatical error on the Internet is likely to make an error of the same sort himself in the critique.
Or you can just download it if you don't want support. [shrug].
They're using subdermal chips on animals now -- basically, the guts of a smartcard yanked out and put in an ear or something. Cheaper, easier, and can be handled in an automated manner, unlike brands or tattoos.
And maybe someday people will get this. Of course, at first it will be a convenience, like the first credit cards, and become more and more inconvenient not to have...
The skript kiddies of the 00's:
I hax0r3d your tat00 mAc|-|in3!!!
Talk about a lingering reminder of a break-in.
they think they deserve
The problem is that for centuries, US workers have been *massively* more wealthy than third world workers. You bitch about CEOs having 500 times your salary? How about the workers that *you* are making 500 times more than?
You know how big companies can squash little ones? It isn't necessarily because they're that much more efficient (ever seen overhead at a large company? Stupid decisions, overpriced purchases...) It's because large companies can exploit workers in other nations.
And it isn't just multinationals. We yank oil out of other countries at ridiculously low prices so that we can fuel our good transport system, massively cutting the costs of our centralized production. We make products overseas at brutally low wages and then bring them here. A medium-sized company can pay an import company and get their piece of the overseas profit.
So people on here are bitching about how "the American worker *deserves* more". Don't make me laugh. You're living large off the fruits of other countries, friends. Your complaint is that you don't have the latest model car, or a fucking high-definition TV? The people that your comforts are coming from have issues like *starving*.
Now, if you want to take a much more mercenary approach, like "screw workers in other countries and execs, I'm looking out for #1", that's reasonable. But the moral arguments that are coming up here are laughable. "The CEO makes more money than I do, which is unfair". Christ.
If you work for a software company on a piece of software and go home and start writing an open source equivalent during your strike time?
:-)
Nah, I'd say that this would be significantly more influential than drinking beer at home or picketing or anything that the steelworkers did...
That's a facinating thought. Sure, replacing engineers with an offshore worker saves money...I wonder how hard it is to H1B executives as well? Wouldn't that save...more money per visa, which is a constant cost to the company?
Seems like H1Bs should be aimed at execs, since each visa can save the company more money. Aiming them at engineers is a misuse of company funds.
The body of code that composes Phoenix is part of the Mozilla codebase, and an enormous amount of code is shared between the two.
That's what I meant.
"integration" is a very negative thing from an engineering standpoint -- modularity is almost always better. There's no reason in the least that "integration" implies fast start times, which can be achieved without the mingling of web browser code and the OS that MS did.
People want UI consistency. That's reasonable. That does not imply integration of the guts.
People want good performance. That's also reasonable, and also does not imply integration of the guts (which often makes it more difficult to profile programs and results in reduced performance).
If you want to have a daemon running that kepps your web browser's core bits in memory, or use a RAM disk for it, or not read eight zillion config files at start up, or have your OS use a less retarded dynamic loading mechanism, that's fine. None of that implies integration.
Mozilla is not a good example of an app free of integration -- it itself has about four applications all jumbled together in its guts. Phoenix qualifies, but unfortunately has a huge amount of baggage from Mozilla.
So what you *really* mean is that you don't like Mozilla's shoddy performance and prefer IE, *not* that you "like integration".
An example of modularity -- where each component of a system provides certain services, and if B relies on service A provided by module A1, I can replace A1 with A2 and B will keep working.
*This* is what you nearly always want, not "integration" where A and B become mingled.
I read through a study on this -- economic costs of smoking.
Yes, there are more healthcare costs, but the lifespan expectancy drastically shortens, so smokers are less likely to recieve the benefits of Social Security. Furthermore, when the taxes that smokers pay that go to everyone are factored in, the researchers concluded that smokers actually are an economic benefit to non-smokers (of course, they certainly could have missed some factors).
The total economic benefit of someone smoking a pack of cigarettes to the non-smoking community was estimated to be something like ten cents, IIRC.
The overwhelming factor is that smokers tend to die early, and never enjoy their retirement.
If anyone's still dumb enough to be smoking, that study should have put them off...
I believe there's a 1.0 maintainer.
Unlike Windows, where your code rapidly becomes unmaintained...about a five year lifespan.
I use 2.4, but your complaining is silly.
I have a PS/2 keyboard, as do 99% of PC users. I use a PS/2 mouse, which is getting a little less common, but *hardly* unheard of (esp. since Logitech makes PS/2-and-USB compatibile mice).
2.2 would work quite fine for a server.
I dunno. The description sounds good. I *hate* wire work...:-)
No, "Windows" is a generic term used for a particular element of a GUI. It's not a generic term for an operating system as a whole.
Also, trademark law is built mostly to prevent companies from profiting by consumer confusion. There's a pretty strong argument (see my first post) that that's what the Lindows people were trying to do. So, yes, I don't think that "Lindows" is a reasonable choice on the part of the Lindows people.
Because company A is large and not making idle threats about suing, and company B's costs in changing their name may be less than paying for defending against the lawsuit (which they might end up losing, anyway).
The GTK/GTNOME people did it at first, but there's so much GNOME software now that it's pretty much abandoned -- essentially no new software starts with a g.
The KDE folks are still guilty. It makes the product names sound *dumb*, not "integrated" or whatever they're trying.
Actually, the article author planned all this in advance, and the entire point of the article was to produce this thread.
It's kind of ugly for everyone involved. "window" is definitely a generic term for a windowing interface. When MS chose the term "Microsoft Windows", they sure as hell weren't thinking of trademark issues.
The problem is that then Lindows came out. Now, "Lindows" isn't just a windowing system -- it's an operating system, rather similar to what MS is selling. Furthermore, Wal-Mart sells these damn little boxes to people who have little computer experience and say that they have "Lindows" and are "Windows compatible". There's a pretty good case for confusion there if you have an inexperienced buyer. I don't have a lot of sympathy for the Lindows people -- I think it's fair to claim that they were trying to take advantage of confusion.
So MS sues them. Probably the only justified legal move MS has made in the last decade. The judge not *only* denies the injunction, but states that "Windows" is/has become a generic term. So now Microsoft is panicking and trying to do damage control to regain control of their product name. They go after everyone using Windows to try to build up a stronger case for future trademark infringement suits. There's nothing MS would hate more than ten companies out of China selling WINE+Linux+GNOME systems called "Super Windows".
Frankly, this whole thing wouldn't have happened if the Lindows people hadn't pulled their attempt to grab a little MS market share...
Microsoft chose to call their product "Microsoft Windows" in an attempt to get product-company association. That's fine, but they forego the ability to attack people making products called "Remote Windows" or "CacheWindows".
Oh, they'll probably make some stupid case about how the thing is close enough to cause confusion, but I have a hard time seeing a judge buying it.
Emacs is hardly incomprehensible. It's broken into small packages, each of which can be pretty easily understood and extended.
Apple has a bug. This is amazing news.
/me thinks Apple would have been better using someone else's kernel -- like the FreeBSD one -- verbatim instead of trying to hack up that Mach POS (which I've heard nothing but bad things about from OS people up at Carnegie Mellon, where Mach was developed). They could still have plopped Carbon and Quartz and all their other goodies on top.
I'd say it's pretty notable. Apple's never been noted for particularly buggy code, though OS X has had a fairly nasty number of things like kernel oopses since its introduction. So while it's not *that* out of line for issues to pop up in a youthful OS, the amazing thing is that this didn't show up before.
Of course, I certainly could be missing something -- could be that the FBSD kernel just didn't do something that Apple had to have it do, and that the FBSD people wouldn't have accepted. Could be SMP issues, I suppose...
More like non-existant
I believe that classic MacOS could do preemptive threading of some sort, but only with 680x0 code, not PPC.
I got interested in writing threaded stuff under the MacOS at one point, so this is out of hazy memory here.
Take a look at the SEDA link I gave you
It was broken, but I found it via google. Okay, fine. What I assume the relevant information is at the site is Despite using Java, we have achieved performance that rivals (and sometimes exceeds) that of C/C++. The point of his paper was that the particular architecture he was using, *even though* implemented in Java, performed better than Apache and some other webserver called Flash that I haven't heard of. It's comparing architecture 1 in Java versus architecture 2 in C. If he wants to build an architecture 1 server in C, there might be more grounds for comparison. Apache certainly does not represent a performance cap on C -- there are many webservers written in C that outperform Apache -- Boa and Tux are two off the top of my head, though I'm sure I could find more if I went looking.
I thought you wanted to trade features and convenience for speed. Or is it some features and convenience.
Oh, I want to be able to code in the thing, sure. It's quite feasible to code large scale software projects in C, as has been demonstrated many times. It simply isn't feasible to do the same in assembly (granted, there has been some work on oddities like typed assembly language, but they're nothing more than research projects, and I doubt they'll ever add up to much.). I want a language that places a few constraints on the software author to improve the optimizer. Ocaml is a good example that good speed and functionality can be had together -- now, the only thing that needs to be done is produce a popular, imperative language that has good performance. (Not all of us are functional language fans.)
I don't think I was talking about the language specs at that point. Rather implementations.
Okay, fine. Blackdown Java doesn't use pthreads. It also eats more memory (and, incidently, runs more slowly than IBM's JVM, which does use pthreads.)
And it certainly is possible to write Java progs which scale better than equivalent C programs. On the same hardware. It has been done.
I can write a bublesort in C and a quicksort in Java or visa versa. My beef is that the Java language puts fundamental caps on performance that I think are unwarranted and unnecessary, regardless of whether the language is "modern" or not.
Okay, gets() has been judged to have risks higher than the worthwhile benefits, and has been obsoleted. GCC at least will issue a warning when you use it. There are certainly times when using gets() could be justified -- if, for instance, I have a program that uses IPC through stdin, so I have guarantees on the length of the buffer -- the code on each end is trusted. This way, I don't have to check lengths. However, there's no requrement to use gets() if it's not appropriate for your situation (i.e. reading in data from the user), since fgets() exists and works just fine.
Just to give you some perspective, I was arguing about language performance some time ago on Slashdot and someone mentioned that IBM had added or was considering adding an option to disable bounds checking on arrays precisely because of the performance hit. People *care* about the peformance involved in bounds-checking everything. If you're using the appropriate API call for the appropriate situation, there's no problem.
This is relevant to our discussion, since you wrote speed is almost everything in a language...if you trade those goals in a language design for speed, you would very unlikely find fixing these issues in the future easy. While performance issues can be dealt in the implementation far easier than breaking languages.
I said that functionality could be added later -- performance limitations stuck with developers forever. You said that functionality should be added soon and performance worried about later. I responded and said that this *had* happend via libraries like glib for C. You complained that functionality was being added to libraries, rather than (technically) to the language. I said that it was an issue of semantics -- that whether the improvements added keywords or functions didn't matter, as long as they added the needed functionality. I still stand by that, and I don't see how what you wrote here is a rebuttal to that.
Maybe not order, maybe just one order.
I'm very dubious that you could even manage one order. Perhaps there's a case somewhere that could do this, but in general, even a few years back when compilers were much less good, recoding inner loops was unlikely to buy you anything like this. As I pointed out, Rasterman was unable to improve on current gcc code.
The point is, these are all trade offs, Java and Erlang are higher-level languages than both C and assembly, and raw speed is definitely a trade-off for convenience, portability, etc., etc.
I disagree that raw speed must be traded to achieve convenience. I'm not a huge fan of ocaml the language, but ocaml code is extremely portable, runs nearly as fast as C, and is a very high-level language. Both speed and modernity can be achieved.
C compilers could get significantly better optimization (and add better checking and modern features) if an additional series of constraints were laid on top of the very free-form C. There are a few languages that do this sort of thing now. Splint, for instance (a lint for C that can handle extra constraints on C), can do this a little. I've seen more involved ones, though I don't have names handy.