That's nonsense. VNC does not allow you to "setup a Windows box and have 50 Linux desktops connect to it"--VNC doesn't magically transform a single user Windows machine into a multiuser machine. I wish it did, but XP is such a primitive system that that's not easily possible. As far as Windows is concerned, VNC gives you the ability to remotely control a machine into which you are logged in, no more.
In any case, what matters is not whether VNC lets you do this but that Microsoft tries to impose such restrictions. It's just another indication of how much they are trying to milk and control their customers. Any rational buyer should run from that kind of company, and this should be added to the long list of anticompetitive practices to be investigated.
Sirius should have thought of this before investing $3bn. Sirius knew beforehand where they ended up on the spectrum and where the unlicensed users were going to be. If the slot they got a license for didn't suit them, they should have picked a different one.
In any case, I don't think they have much to worry about. Come on, 55MHz is a lot of spectrum between them and 802.11b.
On the other hand, I also don't think that rampant commercial use of 802.11b is desirable either. If you want to use it at home, that's fine. If some ISP uses it to provide service, I think that's not OK, not because it interferes with Sirius but because it interferes with private users of the spectrum.
Actually, Sun has painted themselves into a corner. Sun used to be the de-facto standard for science and engineering. Nowadays, most scientists and engineers have a PC (often running Linux) or Mac on their desk and Sun only sells to a tiny high-end specialty market. Even in the big server market, Linux clustering beats Sun hands down for many applications in terms of bang-for-the-buck.
64bit processing is not compelling enough to cause a lot of people to switch. With cheap memory, that will change over the next couple of years, but then AMD and Intel will have mature 64bit offerings.
Sorry, but Sun has been steadily going downhill. They just don't have much of a market anymore.
Nevertheless, the price/performance ratio of Intel is better than that of the Suns. That is true also for parallel applications.
What Sun gives you is a bit more performance per processor, or a bit more performance per multiprocessor box. But that is not usually a compelling argument, since big computations are usually distributed anyway, and it's still cheaper to build a 200 processor Beowulf cluster than to buy a 100 processor SPARC box. (The Beowulf probably also gives you better I/O and memory bandwidth overall.)
What we really need is a package system in which programs declare exactly and ahead of time what kinds of things they want to do. The user should be able to set policies (with reasonable default policies), and the installer and kernel should enforce them.
In particular, by default, neither the installer nor the actual application software should be able to replace system libraries, install executables with pre-existing meanings, or even access files that are of types different from the ones it is intended to operate on.
Unfortunately, none of the installers on any of the common platforms enforce much of anything. Installers usually can run arbitrary scripts, and once installed, applications are free to do whatever they want. And specifications of what an installer does are also incomplete, even in systems like RPM and Debian.
If you want leak detection and garbage collection, use the Boehm/Weiser/Dehmers garbage collector. It works with C, C++, and a lot of other languages. Mozilla should probably be using it by default. For plain leak detection, there are plenty of highly functional open source packages. "dmalloc" comes to mind (although it's not completely unencumbered). For array bounds violations, you can use valgrind, ElectricFence, and other free tools.
A more basic question to ask, however, is why something like Mozilla has memory leaks in the first place. Avoiding memory leaks in C is hard because there simply are no hooks in C to automate resource management. But C++ has constructs that make writing leak-free code and code that doesn't use bad pointers pretty easy. Since switching from C to C++ a few years ago, memory leaks and bad pointers have simply not been an issue anymore in my code.
If you have multiple developers creating conflicting patches, they are working on the same part of the code and they need to coordinate and communicate. There is nothing that CVS or any other version control system can do about that.
How they communicate is a separate issue. IRC works for some projects; IM is another choice. CVS also offers file-level locking and that can be used to communicate that someone is preparing a patch for a file, but it requires planning ahead and splitting up files.
That would be silly. The "bad people from Audiotron and Yamaha" could just use an open protocol if they didn't want to spend the couple of hours to cook up their own.
Guess you'll just have to install Windows to use it.
I think I'll just take my dollars to a more clueful vendor. Even if I were to use this on Windows, why would I want a device that's tied to software that's likely to be obsolete with the next Windows release? Thanks, but no more expensive doorstops for me.
I don't get it. Why don't people who manufacture these devices document the protocol and put it up on the web? They'd have Linux and MacOS support within days.
Small "nukes" may or may not be weapons of mass destruction. After all, the fallout can endanger a lot of people, and even subcritical dirty bombs have been talked about as "weapons of mass destruction" by US politicians. And I suspect that if Iraq had a kiloton nuclear device, Bush would be foaming at the mouth about "weapons of mass destruction".
Be that as it may, you wrote "Nukes do not equal weapons of mass destruction". I take it that's not what you meant, then?
Suppose there is a new metadata field for "last accessed from". In this case the "open(*FILE)" call would need a new parameter
Yes, and this is the heart of the problem with the Microsoft proposal: they appear to allow metadata to be defined by anybody. But my application won't know about what metadata fields other applications expect or what they mean if they aren't standardized. This is an intrinsic problem with the general-purpose metadata proposals that have come and gone over the decades.
The other issue is where metadata gets implemented. The only metadata that it makes sense to put into the kernel is the metadata the kernel actually needs to know about or update. That is, ownerships, permissions, modification times, etc. Keywords, search indexes, and all that stuff doesn't need to be in the kernel because it isn't related to issues of access control or resource management. If you want that kind of additional metadata, you can either put it into the file itself or you can put it into a separate file alongside the main content (the choice depends on the semantics you want) and access it through a library. I believe Gnome gets this right.
This stuff has been thought over for decades, and it has been tried in numerous systems. It has failed to catch on outside niche markets because it just isn't good engineering for general purpose computers.
The only thing Linux is missing in this regard is a standard mechanism for file change notification in the kernel.
The've been trying to do this for years, but backward compatibility issues keep forcing them to abandon it.
It's not just backwards compatibility. The idea of putting metadata into the file system itself is broken and that's the real reason why it hasn't caught on.
What's wrong with it? If your files are associated with metadata, you need to maintain it and programs need to deal with it. How should the metadata get copied? What do you do with it if the file is accessed through HTTP? Proponents always think this is merely an issue of standardization, but it isn't: it's an intrinsic problem with metadata.
Furthermore, most stuff on disks doesn't need to be indexed at all, and it makes no sense to pay the considerable overhead of a general purpose metadata and indexing mechanism.
We have good ways of dealing with metadata already, ways that are adapted to the needs we have. The file system code is the wrong place to implement metadata in a general purpose operating system: it's a confusion of different layers of abstraction.
So, if Microsoft's approach is (as usual) wrong, what's the right approach? ReiserFS with change notification is a good candidate. If you need to associate different pieces of information, your "document" turns into a directory, and the data and metadata streams live inside that directory. This is, incidentally, also the approach MacOSX takes. It's flexible and it's simple. Even if it weren't backwards compatible, it would be the right thing to do.
That's perfectly ridiculous. Of course, nuclear weapons are weapons of mass destruction; if they aren't, what is? And, in case you haven't been paying attention, the whole discussion is about nuclear weapons ("nuclear bunker busters", "Pentagon report", etc.), not about engineering applications of nuclear explosives.
You can lead a horse to water, but you can't make it drink. Anybody and everybody in the US has all the resources to become as tech-savvy as they like. No, the US isn't an egalitarian country, and there is discrimination and all sorts of other obstacles. But there still is a public education system that is decent in many places. You get lots of libraries, with Internet access even. There is job retraining. There are charities that make computers available. And software like Linux makes technology available to people that a decade or two ago would have been out of the reach of any but a few lucky researchers with lots of money.
If people aren't tech savvy, it's because they don't want to be. Culturally, they are conditioned to think that it's not "cool", that it's "too geeky", and that becoming a lawyer, PR spokesman, manager, or politician is just so much better.
In the US, the market satisfies demands. On the whole, people are getting the technology they ask for. They don't want to be tech savvy, they aren't willing to pay extra for reliability or ease-of-use, so they end up with something like Windows. Geeks have been preaching the importance of technology forever, but people aren't listening. What more do you want?
If you ask "should the creation of software be taxed", that sounds just weird. If you ask, "should a company like Microsoft pay a small part of their revenue stream, however generated, into the local economy where the revenue is generated", I think the answer is pretty clear. How you calculate that tax is another question. Talking about "taxing software" may not be the right way of doing it. Maybe they should simply stick with business real estate taxes and tax proportionally to the number of employees (because that's what creates the costs for the city).
Business transactions require that you uniquely and unambiguously identify individuals. There is no way around that. The only question is what kind of identifier you use.
The US has chosen social security numbers for its globally unique identifier, just about the worst choice you could make. As a consequence, identity theft is rampant in the US, as are administrative snafus. Also, the US spends enormous amounts of money on border patrols, employment verification, and immgration status verification, when a secure ID card would solve the problem much more cheaply and reliably.
The way to fix the problem with SSNs is not to go back to the middle ages and pretend that you can get by in a modern society without a unique identifier. Rather, we need secure, unforgeable, globally unique identifiers. And smartcards are the most promising and least obtrusive way of doing that.
Unique, difficult-to-forge credentials and identifiers are in your and my interest. They aren't in conflict with privacy and security, they support it. It's time that the US gets with it.
Once the first card reader is compromised, or even if someone just reverse-engineers the chip, the whole system is compromised.
If they did the cryptography right, it doesn't rely on obscurity--even perfectly disassembling one card should give you at most the information on that card, it doesn't compromise the whole system.
This is their business. They offer a service, no diffrent than AOL or your local cable company. Its more similar to a very good magazine.
AOL and my local cable company don't ask for donations; they have business models that has them provide a product, and people pay in order to get the product.
if you dont subscribe then you want them to run their business more like a Redhat or Suse
Well, there are several collaborative free operating system projects that do not have a commercial tie-in, so it isn't necessary. I just think it would be better if Mandrake declared what they actually want to be: a money-making commercial enterprise, or a community-supported system. I think it's not right to try to be both, because any company that tries to be both is basically just turning volunteer labor into profits.
By all means, if you think Mandrake is the best thing since sliced bread, support them. However, I think given that they want to be a company that wants to derive profit from making a Linux distribution people will buy, one may well ask the question: why? There is nothing wrong with being for-profit, but if they can't make a good business out of it now, why should they be able to in the future?
Every time I've played with Java it's really slow at data access. Fast array access is needed for things that have high user interactivity (games, graphics applications, simulations, etc.).
1D array access is fast in Java. What is slow in Java is initial startup (class loading and first JIT pass). There are also some unexpected performance pitfalls, but they can be worked around.
O'Caml shows how you can make a "safe" language that is plenty fast.
O'CAML is nice, but it doesn't have quite the dynamic/reflection facilities of Java and, in my experience, performs no better than Java. (However, its runtime footprint is slower.)
What they need to do is make a real compiler, just like the olden days before C. That's why C is so fast,
C isn't particularly fast on modern hardware: C compilers cannot apply a lot of optimizations. Some numerical FPs already outperform C, and JITs likely will as well.
I wouldn't be so sure about that, Microsoft will make sure it's really freaking fast.
Well, we don't have to guess about what C# and CIL looks like--they are documented. They have a couple of features (value classes, multidimensional arrays, unsafe sections) that are convenient for expressing a few programs more efficiently, but if anything they make C# harder to compile.
Microsoft will try to deliver a really high performance implementation of C#, but Sun already has done most of the work and Sun has a really high performance implementation of Java. It would be nice if Sun added some features in C# to Java, but for most applications, it doesn't make any difference.
I haven't seen where O'Caml is a whole lot slower than C in anything [...], can you give an example?
Mostly on code involving value classes and heavy-duty numerics. Try writing a convolution algorithm.
I know, I was just stating what my perfect language would be like. It has yet to be invented AFAIK.
That's probably for the same reason there is no perfect car or camera: it's all engineering tradeoffs.
I've always heard a source-to-native compiler can make much better optimizations than a JIT compiler.
A JIT compiler not only has complete source code and (usually) the whole program available (Java byte code is, for practical purposes, equivalent to source code), it also can collect detailed runtime statistics. So, a JIT can do much better than a batch compiler. For example, gcj cannot usefully inline methods calls like "obj.method()" in situations where a JIT often can.
Both CIL and JVM implementations need to perform this "dataflow analysis" as part of the byte code verification. And it's trivial to implement--a few pages of code.
From the beginning C# has been made to be natively compiled if desired and that means speed.
C# isn't any easier to compile to native code than Java. In fact, C# is basically Java with a few extra convenience features thrown in.
Even GCJ generates large and slow code (compared to say, O'Caml).
What do you mean by "even GCJ"? GCJ is not a very good Java compiler. Sun's JIT is much better. To implement a language like Java or C# efficiently, you need JIT compilation.
In my own testing I've found O'Caml to be not much slower than C, even with array bounds checking turned on, that's quite impressive.
O'CAML, like Java, sometimes gets close to C performance and sometimes misses by a long shot. And C# won't be any different.
My perfect language would be a type-safe, bounds-safe, inferencing, C-like language with OO extensions (but not go off the deep end of OO like C++ did). And it should create programs that run at the same speed as C (or real close). In other words, I want O'Caml with a C-like syntax.
Don't hold your breath. Neither the JVM nor the CLI have anywhere near the support you need for that.
Slashdot Mirror
In any case, what matters is not whether VNC lets you do this but that Microsoft tries to impose such restrictions. It's just another indication of how much they are trying to milk and control their customers. Any rational buyer should run from that kind of company, and this should be added to the long list of anticompetitive practices to be investigated.
In any case, I don't think they have much to worry about. Come on, 55MHz is a lot of spectrum between them and 802.11b.
On the other hand, I also don't think that rampant commercial use of 802.11b is desirable either. If you want to use it at home, that's fine. If some ISP uses it to provide service, I think that's not OK, not because it interferes with Sirius but because it interferes with private users of the spectrum.
Actually, our Linux Beowulf cluster is in our machine room, next to a (now unused and defunct) Sun Enterprise server.
64bit processing is not compelling enough to cause a lot of people to switch. With cheap memory, that will change over the next couple of years, but then AMD and Intel will have mature 64bit offerings.
Sorry, but Sun has been steadily going downhill. They just don't have much of a market anymore.
What Sun gives you is a bit more performance per processor, or a bit more performance per multiprocessor box. But that is not usually a compelling argument, since big computations are usually distributed anyway, and it's still cheaper to build a 200 processor Beowulf cluster than to buy a 100 processor SPARC box. (The Beowulf probably also gives you better I/O and memory bandwidth overall.)
In particular, by default, neither the installer nor the actual application software should be able to replace system libraries, install executables with pre-existing meanings, or even access files that are of types different from the ones it is intended to operate on.
Unfortunately, none of the installers on any of the common platforms enforce much of anything. Installers usually can run arbitrary scripts, and once installed, applications are free to do whatever they want. And specifications of what an installer does are also incomplete, even in systems like RPM and Debian.
A more basic question to ask, however, is why something like Mozilla has memory leaks in the first place. Avoiding memory leaks in C is hard because there simply are no hooks in C to automate resource management. But C++ has constructs that make writing leak-free code and code that doesn't use bad pointers pretty easy. Since switching from C to C++ a few years ago, memory leaks and bad pointers have simply not been an issue anymore in my code.
How they communicate is a separate issue. IRC works for some projects; IM is another choice. CVS also offers file-level locking and that can be used to communicate that someone is preparing a patch for a file, but it requires planning ahead and splitting up files.
Guess you'll just have to install Windows to use it.
I think I'll just take my dollars to a more clueful vendor. Even if I were to use this on Windows, why would I want a device that's tied to software that's likely to be obsolete with the next Windows release? Thanks, but no more expensive doorstops for me.
For laptops and PDAs, which may get lost or stolen, it makes sense to encrypt passwords and account numbers
I don't get it. Why don't people who manufacture these devices document the protocol and put it up on the web? They'd have Linux and MacOS support within days.
Be that as it may, you wrote "Nukes do not equal weapons of mass destruction". I take it that's not what you meant, then?
Yes, and this is the heart of the problem with the Microsoft proposal: they appear to allow metadata to be defined by anybody. But my application won't know about what metadata fields other applications expect or what they mean if they aren't standardized. This is an intrinsic problem with the general-purpose metadata proposals that have come and gone over the decades.
The other issue is where metadata gets implemented. The only metadata that it makes sense to put into the kernel is the metadata the kernel actually needs to know about or update. That is, ownerships, permissions, modification times, etc. Keywords, search indexes, and all that stuff doesn't need to be in the kernel because it isn't related to issues of access control or resource management. If you want that kind of additional metadata, you can either put it into the file itself or you can put it into a separate file alongside the main content (the choice depends on the semantics you want) and access it through a library. I believe Gnome gets this right.
This stuff has been thought over for decades, and it has been tried in numerous systems. It has failed to catch on outside niche markets because it just isn't good engineering for general purpose computers.
The only thing Linux is missing in this regard is a standard mechanism for file change notification in the kernel.
It's not just backwards compatibility. The idea of putting metadata into the file system itself is broken and that's the real reason why it hasn't caught on.
What's wrong with it? If your files are associated with metadata, you need to maintain it and programs need to deal with it. How should the metadata get copied? What do you do with it if the file is accessed through HTTP? Proponents always think this is merely an issue of standardization, but it isn't: it's an intrinsic problem with metadata.
Furthermore, most stuff on disks doesn't need to be indexed at all, and it makes no sense to pay the considerable overhead of a general purpose metadata and indexing mechanism.
We have good ways of dealing with metadata already, ways that are adapted to the needs we have. The file system code is the wrong place to implement metadata in a general purpose operating system: it's a confusion of different layers of abstraction.
So, if Microsoft's approach is (as usual) wrong, what's the right approach? ReiserFS with change notification is a good candidate. If you need to associate different pieces of information, your "document" turns into a directory, and the data and metadata streams live inside that directory. This is, incidentally, also the approach MacOSX takes. It's flexible and it's simple. Even if it weren't backwards compatible, it would be the right thing to do.
That's perfectly ridiculous. Of course, nuclear weapons are weapons of mass destruction; if they aren't, what is? And, in case you haven't been paying attention, the whole discussion is about nuclear weapons ("nuclear bunker busters", "Pentagon report", etc.), not about engineering applications of nuclear explosives.
If people aren't tech savvy, it's because they don't want to be. Culturally, they are conditioned to think that it's not "cool", that it's "too geeky", and that becoming a lawyer, PR spokesman, manager, or politician is just so much better.
In the US, the market satisfies demands. On the whole, people are getting the technology they ask for. They don't want to be tech savvy, they aren't willing to pay extra for reliability or ease-of-use, so they end up with something like Windows. Geeks have been preaching the importance of technology forever, but people aren't listening. What more do you want?
If you ask "should the creation of software be taxed", that sounds just weird. If you ask, "should a company like Microsoft pay a small part of their revenue stream, however generated, into the local economy where the revenue is generated", I think the answer is pretty clear. How you calculate that tax is another question. Talking about "taxing software" may not be the right way of doing it. Maybe they should simply stick with business real estate taxes and tax proportionally to the number of employees (because that's what creates the costs for the city).
The US has chosen social security numbers for its globally unique identifier, just about the worst choice you could make. As a consequence, identity theft is rampant in the US, as are administrative snafus. Also, the US spends enormous amounts of money on border patrols, employment verification, and immgration status verification, when a secure ID card would solve the problem much more cheaply and reliably.
The way to fix the problem with SSNs is not to go back to the middle ages and pretend that you can get by in a modern society without a unique identifier. Rather, we need secure, unforgeable, globally unique identifiers. And smartcards are the most promising and least obtrusive way of doing that.
Unique, difficult-to-forge credentials and identifiers are in your and my interest. They aren't in conflict with privacy and security, they support it. It's time that the US gets with it.
If they did the cryptography right, it doesn't rely on obscurity--even perfectly disassembling one card should give you at most the information on that card, it doesn't compromise the whole system.
AOL and my local cable company don't ask for donations; they have business models that has them provide a product, and people pay in order to get the product.
if you dont subscribe then you want them to run their business more like a Redhat or Suse
Well, there are several collaborative free operating system projects that do not have a commercial tie-in, so it isn't necessary. I just think it would be better if Mandrake declared what they actually want to be: a money-making commercial enterprise, or a community-supported system. I think it's not right to try to be both, because any company that tries to be both is basically just turning volunteer labor into profits.
By all means, if you think Mandrake is the best thing since sliced bread, support them. However, I think given that they want to be a company that wants to derive profit from making a Linux distribution people will buy, one may well ask the question: why? There is nothing wrong with being for-profit, but if they can't make a good business out of it now, why should they be able to in the future?
1D array access is fast in Java. What is slow in Java is initial startup (class loading and first JIT pass). There are also some unexpected performance pitfalls, but they can be worked around.
O'Caml shows how you can make a "safe" language that is plenty fast.
O'CAML is nice, but it doesn't have quite the dynamic/reflection facilities of Java and, in my experience, performs no better than Java. (However, its runtime footprint is slower.)
What they need to do is make a real compiler, just like the olden days before C. That's why C is so fast,
C isn't particularly fast on modern hardware: C compilers cannot apply a lot of optimizations. Some numerical FPs already outperform C, and JITs likely will as well.
Well, we don't have to guess about what C# and CIL looks like--they are documented. They have a couple of features (value classes, multidimensional arrays, unsafe sections) that are convenient for expressing a few programs more efficiently, but if anything they make C# harder to compile.
Microsoft will try to deliver a really high performance implementation of C#, but Sun already has done most of the work and Sun has a really high performance implementation of Java. It would be nice if Sun added some features in C# to Java, but for most applications, it doesn't make any difference.
I haven't seen where O'Caml is a whole lot slower than C in anything [...], can you give an example?
Mostly on code involving value classes and heavy-duty numerics. Try writing a convolution algorithm.
I know, I was just stating what my perfect language would be like. It has yet to be invented AFAIK.
That's probably for the same reason there is no perfect car or camera: it's all engineering tradeoffs.
I've always heard a source-to-native compiler can make much better optimizations than a JIT compiler.
A JIT compiler not only has complete source code and (usually) the whole program available (Java byte code is, for practical purposes, equivalent to source code), it also can collect detailed runtime statistics. So, a JIT can do much better than a batch compiler. For example, gcj cannot usefully inline methods calls like "obj.method()" in situations where a JIT often can.
Both CIL and JVM implementations need to perform this "dataflow analysis" as part of the byte code verification. And it's trivial to implement--a few pages of code.
C# isn't any easier to compile to native code than Java. In fact, C# is basically Java with a few extra convenience features thrown in.
Even GCJ generates large and slow code (compared to say, O'Caml).
What do you mean by "even GCJ"? GCJ is not a very good Java compiler. Sun's JIT is much better. To implement a language like Java or C# efficiently, you need JIT compilation.
In my own testing I've found O'Caml to be not much slower than C, even with array bounds checking turned on, that's quite impressive.
O'CAML, like Java, sometimes gets close to C performance and sometimes misses by a long shot. And C# won't be any different.
My perfect language would be a type-safe, bounds-safe, inferencing, C-like language with OO extensions (but not go off the deep end of OO like C++ did). And it should create programs that run at the same speed as C (or real close). In other words, I want O'Caml with a C-like syntax.
Don't hold your breath. Neither the JVM nor the CLI have anywhere near the support you need for that.