The fact is Jaguar is worth the upgrade price. [...] I've been running the 6C106 developers release and this has to be one of the biggests upgrades in apple history in terms of big and little things that are different.
The software development costs are a small fraction of the retail package price, so arguments that it is "worth it" based on functionality are almost meaningless.
What it comes down to is that Apple needs money again to make the stock holders happy, and they have something that a sufficient number of people are going to buy, whether its is earth-shatteringly different or merely a so-so upgrade. And the reason why Apple gets to set the prices is because Mac users have already sunk costs into their machines--they aren't going to switch because of a $120 upgrade. But if Apple does that too often, they risk losing customers.
There is nothing wrong with any of that. We knew that Apple and other companies work that way when we bought our Macintoshes.
I'm probably not going to upgrade: my Mac does exactly what I want, and I see no point in paying money and risking that it will get slower or stop working altogether.
This has nothing to do with Apple. The only thing this issue brings up is that Apple users are apparently rather cheap, just as Linux users are. Or at least the people who whine online are cheap. So it goes.
Rational agents in a market economy are "cheap". That's what makes market economies efficient. It's the people who are not "cheap" that create problems for the market. Like people who keep paying millions of dollars to outfit their companies with slow, insecure, unreliable, buggy software despite the costs. If those people behaved rationally and were "cheap", certain big computer companies would actually either have to shape up or get out.
Permissions can also be assigned to certain branches and keys of the registry to restrict access. Plus it's a database file, as long as no more than one process is accessing the same record, concurrent use can and does happen. Sorry none of your argument holds up.
Yes, it is a database, but it's a single-purpose database with few tools available for it, so it's not very good. Compare that to using the file system, which has enormous numbers of tools for it out of the box (well, on UNIX, not on Windows) and is one of the most tested and debugged parts of any OS.
Really? That's interesting, I didn't know that, what was it called?
IBM's AIX has using it for a lot of configuration information for many years, but I'm not sure when they started. Several large BSD installations used binary configuration databases (special purpose hacks) in the early 1980s when BSD was just catching on.
I like your last line where you call windows backwards and insult windows administrators. This isn't a holy war, though the term zealot certaintly applies to many OS advocates (where OS = {Open Source, Operating System}).
I just get tired of Windows folks telling the UNIX community that they are backwards. Many of the things that are being advertised on Windows as nifty new features are things people tried in UNIX many years ago and discarded as more trouble than they were worth. The good thing about UNIX and Linux is that it's an ecology of ideas--people try things and if they don't work well, they discard them. With Windows, if Microsoft decides to put something in, either because they don't know any better or because it suits their business folks, it sticks, no matter how stupid or inconvenient it may be for users.
Apparently you don't realise the user and system settings are in completely different 'hive files' (user hives are in the user directories, while the system hives are in the system directory) in the Windows registry. The user interface may make it appear to be a single unit, but it actually comprises multiple files.
You're right about the registry consisting of several files, but however it is split into file, it doesn't seem to be sufficient to let people log into arbitrary NT machines without some additional registry magic.
The main differences versus UNIX are that the registry is not text, so although it is far more efficient to query than text files, it is also much more difficult to use,
That's the theory. In practice, searching through the registry is hundreds of times slower than grepping through/etc. My/etc contains 14Mbytes of stuff. Grepping through that takes 0.086sec (the magic of the file system cache), and I can use whatever tool I like (grep, agrep, perl). Try searching through a 14Mbyte Windows registry for a key.
Also, why optimize something that really is not a performance bottleneck for anything? Reading text configuration files has never been a problem on UNIX; if the configuration is really complex, they just cache a binary version of it (like sendmail).
and the fact that hives are not split per application (which is I think the major flaw).
Splitting it into per-application would be good. But I think using text is good, too, and using file system protections as well. Once you do these three things, you basically have the "UNIX registry"--a directory tree of text files.
The registry has permissions in it--it's how for instance normal users can't changed priviled settings. Secondly, you throw out lots of keywords saying the registry [fails] at them all--how so?
I'm not saying that it fails at them all. I'm saying that Windows uses a buggy, slow, special purpose database that requires separate tools to manipulate it. UNIX uses the same database it uses for many other purposes: the file system. That means you don't need special tools, performance is great, and it gets tested and beaten on much more than the registry code.
Humans are probably resposible for many of the extinctions of large animals everywhere. Pate and scrambled eggs from 9ft ducks can feed a lot of hungry mouths.
So, HP wants third parties to supply them with bug reports and fixes but not to have that information become public. So, basically, HP wants third parties to do their quality control and bug fixing for them for free, without even the scrutiny and quality control that goes along with an open process. And if you merely report publically that a bug and want to get paid in order to fix it, you run the risk of getting accused of blackmail.
I'd say: why help those companies in the first place? They charge an arm and a leg for their defective software, let them fix it themselves. If their software doesn't work as advertised, sue them if your contract permits it, or switch to something else. Don't waste your time and money on doing some vendor's quality control for them.
Some applications need to display real-time graphics or even have real-time interaction. HTTP doesn't support that very well. This does.
Another alternative would be to write the GUI in Java, have a small web server, and some client server protocol. But that may be more work in the end and take more space on the embedded system.
We have needed the floppy drive because it's the one component everything can talk to even when there is nothing else running on the system.
Now, CD-ROMs have started to fill that niche, and CD-R drives are widespread enough to replace the floppy. But CD-R/CD-RW disks are a hassle to create and update, and not every machine comes in a form factor where a CD-ROM makes sense. And 700M is just not a lot of space for distribution media anymore.
What I would like to see even more is for the BIOS, flash updates, and other system software to simply know how to talk to USB mass storage devices. USB ports are really cheap and almost every machine can have one. USB interface cards seem fairly well standardized. That way, I get a wide variety of choices for system installation. Imagine: you could put the latest Linux distribution, BIOS updates, and other software on a USB pocket drive and install it by just plugging it into any USB port and rebooting.
How does a binary file get corrupted? Same way any file gets corrupted. hardware errors are one way. Can you think of any more?
For the registry, there are plenty. For example, if the file system fills up during some registry operations, you're in deep trouble. With separate text files in/etc, that's not a problem: maybe the one file you were writing gets truncated (easy to diagnose and fix), but the others are never touched. You also get separate permissions for each set of settings, and you can use standard file system tools. The file system is a secure, concurrent, multi-user, hierarchical, distributed database, something the registry tries to be but fails at miserably.
Maybe not, but it sure beats searching/etc, subdirectories, user home directories,/usr/local/etc, and other similar locations.
Quite to the contrary. The separate storage locations of user settings and system settings in the UNIX way is one of the big advantages over the registry, as is the fact that you can use standard commands like "grep -Irs mykey/etc" to search. As a system manager, all you have to be concerned with is/etc and/var. Users automatically get their settings everywhere they log on because of file sharing. Windows, in contrast, first blends everything together and then has complicated schemes for distributing user settings again. It's something worthy of Rube Goldberg. It would be funny if it didn't make the lives of thousands of system managers miserable.
That's of course the great thing about choice and competition. The windows world moved away from where the unix world is today since windows 3.1 (registy might have existed before then). I for one am glad that there are no longer a million.ini files sitting around.
The UNIX world tried registry databases before Windows 3.1 was even around and it was the same adminstrative nightmare as the Windows registry. Sticking all configuration information into a single database is just a bad idea. Windows is just so backwards that Windows administrators don't realize it yet.
likewise if your/etc directory got corrupted, you'd be in trouble
You would be. But unlike the Windows registry, which in practice gets corrupted with some regularity,/etc just does not usually get corrupted. That's because people put a lot of effort into making the file system bulletproof.
I searched through my registory for a non-existent string just now in 1 minute and 2 seconds.
Wow, imagine that. Compared to 0.016 seconds for grepping through the files in/etc, or 0.162 seconds for grepping through the whole tree under/etc, I'd say that is "forever".
That's really unfortunate--maybe you should try to do some more learning in the windows world, this is an incredibly easy thing to do. Open regedit, find SSH settings, right click on the directory side the key, select "export". Copy this file to the new machine, double click, you're done.
So, basically, you are saying that your procedure for moving application settings under Windows is: click around in regedit guessing what keys might or might not belong to an application (most Windows programs don't document that), export it somehow, drag and drop it onto the other machine (let's hope it exports its file systems), log in there, and then add it back in with regedit on that side. Then you cross your fingers hoping you didn't make something inconsistent in the registry. And you think that's some way to manage systems?
What do you do in UNIX? You look at the manual page for the documented location of the configuration file and copy it with "scp/etc/something root@remote:/etc/something". That takes a few seconds, before your first search through the registry has even finished.
What do you mean by "system manager"? I'm assuming you mean managing a single system, becasue the knowledge level and ignorance here is shameful for any kind of system administrator.
How very amusing. Let your and my technical comments speak for themselves.
You miss.ini hell (or in the unix world have a billion files in the/etc dircetory).
.INI hell was a consequence of a couple of poor design decisions with.INI files, among them that.INI files often held configuration information for multiple users. Putting everything into a single file makes things worse, not better.
all in all the registry as an idea isn't too bad. but like every database it needs tuning and maintaining.
So, let's see: if it gets corrupted, you are in big trouble, applications like regedit take forever to search through it, and it needs regular tuning and maintenance. And as a system manager, I have a hell of a time trying to express simple concepts like "take the configuration of sshd from this machine and put it on that other machine" with the registry. So, what again is "not too bad" about it? I can't think of one feature resulting from putting everything into a single database that I as a user or system manager would care about.
Windows decays because its package management and system resource databases suck. Sorry, but there is no more polite word for it. The registry is a prime example of those gee-whiz solutions ("why don't we put all this information into a 'real' database") that looks neat but just doesn't work well in practice; Microsoft seems susceptible to implementing those kinds of systems.
MacOS's preferred installation method ("drag-and-drop") doesn't suffer quite from the same problems as Windows. It's clean, simple, and easy to understand, and it doesn't leave junk all over the disk in mysterious places. But some applications install differently, and there is no single software update mechanism. Still, so far, OSX is holding up well on my systems, showing no signs of decay. But maintaining applications at the latest versions is a significant amount of work compared to Linux.
For Linux distributions, it depends on the installation and update method. Debian systems can be updated for years without "decay". In fact, I haven't seen one "decay" yet, either ones that are updated regularly or ones that aren't. Because all packages come from a single source, they are all integrated, cross-checked, and tested together, a luxury that neither Windows nor MacOS have.
The fact that, in Linux, each program has its own configuration files, often one system-wide one and one in the user's home directories, also makes Linux enormously more robust. There is no single point of failure and if some program's defaults get corrupted, it's trivial to fix and trivial to tell users how to fix it ("rm.foobar" and you should be fine).
This is illegal. A EULA is covered under copyright.
That may or may not be true. It would mean that you can't use the same contract text for your own contracts. However, aggregation and publishing of EULAs for legal analysis seems like it ought to fall under "fair use".
And stealing IP from lawyers is just asking for trouble.
It's not "stealing" if it falls under "fair use".
Re:probably doesn't work in general
on
Borrowing ROMs
·
· Score: 2
I don't think it matters how I feel about it:-) And IANAL.
I suspect that physical rental of the ROMs would be OK (even if people copy them); that's the same with other digital medial like CDs, DVDs, and game cartridges.
I don't think anybody can say for certain how it would be for electronic rentals of ROMs. I think for e-books there was a lot of wrestling over the issue of electronic rentals over the last few years, and one way or another, it doesn't seem to have become widespread (yet?). Maybe someone knows whether that issue was settled at least legally.
Intel would have to license the X86-64 code from AMD, a fact that might stick in its craw more than just a little.
I don't see why. Instruction sets don't generally seem to be protected by any law. Otherwise, AMD would have had to license the x86 instruction set, which I doubt they did (and if they did, Intel would be in a great negotiating position). Or the various IBM, PDP, and VAX clones would have had to license the respective instruction sets, which, again, doesn't seem to have been the case.
In fact, in their own article on the Transmeta use of x86-64, which they reference, they wrote:
Sources close to AMD said that Transmeta "licensing" the instruction set, which it did last May, meant no more than it had decided to work with the instruction set and there were no real conditions or limitations on use for X86-64 code.
That means that Intel - which as we reported here some time ago has a "skunkworks" preparing a 64-bit backup plan - can freely use the AMD instructions to make a processor, if that's what it chooses to do.
Seems to me that the "Inquirer" agrees that x86-64 doesn't require a formal license.
Intel's VLIW architecture is going to be a pain for compiler writers, greatly limiting the diversity of languages that's likely going to be available. It will probably do well on C and Fortran-based benchmarks, but whether it runs your or my code well is an entirely different question.
I don't particularly like the x86 instruction set, but unless we all switch to Alpha or SPARC, x86-64 makes the most sense to me.
probably doesn't work in general
on
Borrowing ROMs
·
· Score: 2
Commercial rental of copyrighted works is governed by its own set of rules. Libraries and some other institutions are special. Perhaps this would work if it falls under fair use, but then you may not have to worry about "lending" anyway.
That's not circumventing DRM for things you already have fair use on.
Oh, yes, it is. If I want to produce content that can play on a device that only plays content under DRM, I have to sign it with whatever signatures that DRM device expects. And if those devices are made according to the specs of a small consortium of large manufacturers that only let their own content be played on those devices (or charges steep fees to independent producers), I can't distribute my own content to play on those devices.
That's pretty straightforward and even if it perhaps is draconian, it's still only punishing something that's already illegal and that you shouldn't be doing.
If it were already covered by copyright law, then they wouldn't need this legislation. No, this is a set of new rights for things that are currently probably still permissible.
And it's deliberate: a few, powerful, big companies with lots of money and lots of influence think they can monopolize the market. In fact, for CDs and DVDs, that kind of worked--for a while. This new effort won't really work in the long run either, but it could be painful in the short run. And it could be painful for the stockholders in those big companies that don't have a better business plan than to screw their customers.
This whole approach to DRM and software will collapse under its own weight. Nothing will talk to anything else, consumers will be frustrated, and there will be endless lawsuits about monopolies (don't believe for a moment that IBM or Sony are going to hand this to Microsoft for free).
Think about it this way: each consumer has some amount they are willing to pay for entertainment per month--the pie doesn't get any larger. Companies that have lower costs, lower prices, and satisfy consumers more will get that entertainment dollar. Do you really think complex DRM schemes are going to lead to usable and inexpensive devices and content?
What's going to win out in the long run is either no DRM at all or devices that anybody can author to; there won't be any need to imitate Microsoft's or anybody else's signatures. That, or people will just go back to small, live performances. In any case, the big media companies pushing for this are going to lose out. They had a golden era with vinyl and CDs, where they could mass-produce cheaply but consumers couldn't replicate, and there was no alternative or competition. That's over now.
Nevertheless, while it just delays the inevitable, it is disappointing that politicians don't get this. And it is particularly disappointing that some politicians are so much in the pocket of vested interests that they try to push through such legislation without much debate.
Copyright law makes all sorts of exceptions and allows copying under many circumstances. Furthermore, reverse engineering is OK in many countries, both for educational and commercial purposes. Those are fair use rights.
We, the people, have the right to decide what we protect under copyright and what falls under fair use.
Analogies between "intellectual property" and physical property are self-serving and legally inaccurate for the most part. People who say that "piracy is OK" have already given into the mindset. No, piracy is not OK, but copying should not and does not constitute "piracy" under many circumstances.
It's not uncommon with junior open source programmers running of and cloning the project and giving it away for free (smoothwall for example, there are countless of other examples).
If junior open source programmers can "run out and clone the project", then obviously "the project" can't be very big or complicated. If it weren't the "junior open source programmers" that clone it, it would be a competitor, or some other open source project. Perhaps the business management of the project should take then hint and look for a more profitable project.
just a minority are fanaticals but you put yourself in risk hiring people with a open source background.
Yes, you do put yourself at risk: at risk that if you persist in doing something stupid, your programmers are going to run out on you. I'd consider that a benefit. But to each their own.
(smoothwall for example, there are countless of other examples).
Was there actually a company stupid enough trying to make a business out of that?
I've been using it with 2.4.18, and it's been working just fine (I have a USB 2.0 disk). The interface cards are cheap and the throughput is great. And it seems to be a simple extension of USB 1.0, so drivers like USB storage just seem to work. (Firewire, of course, works as well.)
If you use references in C++, you're using pointers. [...] Lots of neat affects are very easy to do with pointers, but a pain to do with arrays. Function pointers come to mind.
C and C++ use the term "pointer" for a lot of things. It is the totality of those things, and the fact that they are all the same datatype, that presents problems.
"Not using pointers" means not using the stuff that is specific to pointers in C/C++: pointers into the middle of arrays, pointer arithmetic, pointers to local variables. Things would be a lot less problematic if "pointer into the middle of an array", "pointer to local variable", "pointer to heap-allocated object", etc., all had different types.
References are not "pointers": you can't do arithmetic on them, you can't store them in data structures, etc., many of the things that cause problems. But even unrestricted use of references is problematic and error prone in C++, and it is best to limit oneself mostly to references to variables passed as function arguments.
You're not particularly creative with pointers, if you honestly believe they can be replaced by arrays.
I am decidedly not creative with pointers. I used to be very creative with pointers, but I found that hand-crafted pointer code that looked "efficient" didn't run any faster on modern hardware and was a lot harder to debug.
Slashdot Mirror
The software development costs are a small fraction of the retail package price, so arguments that it is "worth it" based on functionality are almost meaningless.
What it comes down to is that Apple needs money again to make the stock holders happy, and they have something that a sufficient number of people are going to buy, whether its is earth-shatteringly different or merely a so-so upgrade. And the reason why Apple gets to set the prices is because Mac users have already sunk costs into their machines--they aren't going to switch because of a $120 upgrade. But if Apple does that too often, they risk losing customers.
There is nothing wrong with any of that. We knew that Apple and other companies work that way when we bought our Macintoshes.
I'm probably not going to upgrade: my Mac does exactly what I want, and I see no point in paying money and risking that it will get slower or stop working altogether.
This has nothing to do with Apple. The only thing this issue brings up is that Apple users are apparently rather cheap, just as Linux users are. Or at least the people who whine online are cheap. So it goes.
Rational agents in a market economy are "cheap". That's what makes market economies efficient. It's the people who are not "cheap" that create problems for the market. Like people who keep paying millions of dollars to outfit their companies with slow, insecure, unreliable, buggy software despite the costs. If those people behaved rationally and were "cheap", certain big computer companies would actually either have to shape up or get out.
Yes, it is a database, but it's a single-purpose database with few tools available for it, so it's not very good. Compare that to using the file system, which has enormous numbers of tools for it out of the box (well, on UNIX, not on Windows) and is one of the most tested and debugged parts of any OS.
IBM's AIX has using it for a lot of configuration information for many years, but I'm not sure when they started. Several large BSD installations used binary configuration databases (special purpose hacks) in the early 1980s when BSD was just catching on.
I like your last line where you call windows backwards and insult windows administrators. This isn't a holy war, though the term zealot certaintly applies to many OS advocates (where OS = {Open Source, Operating System}).
I just get tired of Windows folks telling the UNIX community that they are backwards. Many of the things that are being advertised on Windows as nifty new features are things people tried in UNIX many years ago and discarded as more trouble than they were worth. The good thing about UNIX and Linux is that it's an ecology of ideas--people try things and if they don't work well, they discard them. With Windows, if Microsoft decides to put something in, either because they don't know any better or because it suits their business folks, it sticks, no matter how stupid or inconvenient it may be for users.
You're right about the registry consisting of several files, but however it is split into file, it doesn't seem to be sufficient to let people log into arbitrary NT machines without some additional registry magic.
The main differences versus UNIX are that the registry is not text, so although it is far more efficient to query than text files, it is also much more difficult to use,
That's the theory. In practice, searching through the registry is hundreds of times slower than grepping through /etc. My /etc contains 14Mbytes of stuff. Grepping through that takes 0.086sec (the magic of the file system cache), and I can use whatever tool I like (grep, agrep, perl). Try searching through a 14Mbyte Windows registry for a key.
Also, why optimize something that really is not a performance bottleneck for anything? Reading text configuration files has never been a problem on UNIX; if the configuration is really complex, they just cache a binary version of it (like sendmail).
and the fact that hives are not split per application (which is I think the major flaw).
Splitting it into per-application would be good. But I think using text is good, too, and using file system protections as well. Once you do these three things, you basically have the "UNIX registry"--a directory tree of text files.
I'm not saying that it fails at them all. I'm saying that Windows uses a buggy, slow, special purpose database that requires separate tools to manipulate it. UNIX uses the same database it uses for many other purposes: the file system. That means you don't need special tools, performance is great, and it gets tested and beaten on much more than the registry code.
Humans are probably resposible for many of the extinctions of large animals everywhere. Pate and scrambled eggs from 9ft ducks can feed a lot of hungry mouths.
I'd say: why help those companies in the first place? They charge an arm and a leg for their defective software, let them fix it themselves. If their software doesn't work as advertised, sue them if your contract permits it, or switch to something else. Don't waste your time and money on doing some vendor's quality control for them.
Another alternative would be to write the GUI in Java, have a small web server, and some client server protocol. But that may be more work in the end and take more space on the embedded system.
Now, CD-ROMs have started to fill that niche, and CD-R drives are widespread enough to replace the floppy. But CD-R/CD-RW disks are a hassle to create and update, and not every machine comes in a form factor where a CD-ROM makes sense. And 700M is just not a lot of space for distribution media anymore.
What I would like to see even more is for the BIOS, flash updates, and other system software to simply know how to talk to USB mass storage devices. USB ports are really cheap and almost every machine can have one. USB interface cards seem fairly well standardized. That way, I get a wide variety of choices for system installation. Imagine: you could put the latest Linux distribution, BIOS updates, and other software on a USB pocket drive and install it by just plugging it into any USB port and rebooting.
For the registry, there are plenty. For example, if the file system fills up during some registry operations, you're in deep trouble. With separate text files in /etc, that's not a problem: maybe the one file you were writing gets truncated (easy to diagnose and fix), but the others are never touched. You also get separate permissions for each set of settings, and you can use standard file system tools. The file system is a secure, concurrent, multi-user, hierarchical, distributed database, something the registry tries to be but fails at miserably.
Maybe not, but it sure beats searching /etc, subdirectories, user home directories, /usr/local/etc, and other similar locations.
Quite to the contrary. The separate storage locations of user settings and system settings in the UNIX way is one of the big advantages over the registry, as is the fact that you can use standard commands like "grep -Irs mykey /etc" to search. As a system manager, all you have to be concerned with is /etc and /var. Users automatically get their settings everywhere they log on because of file sharing. Windows, in contrast, first blends everything together and then has complicated schemes for distributing user settings again. It's something worthy of Rube Goldberg. It would be funny if it didn't make the lives of thousands of system managers miserable.
That's of course the great thing about choice and competition. The windows world moved away from where the unix world is today since windows 3.1 (registy might have existed before then). I for one am glad that there are no longer a million .ini files sitting around.
The UNIX world tried registry databases before Windows 3.1 was even around and it was the same adminstrative nightmare as the Windows registry. Sticking all configuration information into a single database is just a bad idea. Windows is just so backwards that Windows administrators don't realize it yet.
You would be. But unlike the Windows registry, which in practice gets corrupted with some regularity, /etc just does not usually get corrupted. That's because people put a lot of effort into making the file system bulletproof.
I searched through my registory for a non-existent string just now in 1 minute and 2 seconds.
Wow, imagine that. Compared to 0.016 seconds for grepping through the files in /etc, or 0.162 seconds for grepping through the whole tree under /etc, I'd say that is "forever".
That's really unfortunate--maybe you should try to do some more learning in the windows world, this is an incredibly easy thing to do. Open regedit, find SSH settings, right click on the directory side the key, select "export". Copy this file to the new machine, double click, you're done.
So, basically, you are saying that your procedure for moving application settings under Windows is: click around in regedit guessing what keys might or might not belong to an application (most Windows programs don't document that), export it somehow, drag and drop it onto the other machine (let's hope it exports its file systems), log in there, and then add it back in with regedit on that side. Then you cross your fingers hoping you didn't make something inconsistent in the registry. And you think that's some way to manage systems?
What do you do in UNIX? You look at the manual page for the documented location of the configuration file and copy it with "scp /etc/something root@remote:/etc/something". That takes a few seconds, before your first search through the registry has even finished.
What do you mean by "system manager"? I'm assuming you mean managing a single system, becasue the knowledge level and ignorance here is shameful for any kind of system administrator.
How very amusing. Let your and my technical comments speak for themselves.
You miss .ini hell (or in the unix world have a billion files in the /etc dircetory).
So, let's see: if it gets corrupted, you are in big trouble, applications like regedit take forever to search through it, and it needs regular tuning and maintenance. And as a system manager, I have a hell of a time trying to express simple concepts like "take the configuration of sshd from this machine and put it on that other machine" with the registry. So, what again is "not too bad" about it? I can't think of one feature resulting from putting everything into a single database that I as a user or system manager would care about.
MacOS's preferred installation method ("drag-and-drop") doesn't suffer quite from the same problems as Windows. It's clean, simple, and easy to understand, and it doesn't leave junk all over the disk in mysterious places. But some applications install differently, and there is no single software update mechanism. Still, so far, OSX is holding up well on my systems, showing no signs of decay. But maintaining applications at the latest versions is a significant amount of work compared to Linux.
For Linux distributions, it depends on the installation and update method. Debian systems can be updated for years without "decay". In fact, I haven't seen one "decay" yet, either ones that are updated regularly or ones that aren't. Because all packages come from a single source, they are all integrated, cross-checked, and tested together, a luxury that neither Windows nor MacOS have.
The fact that, in Linux, each program has its own configuration files, often one system-wide one and one in the user's home directories, also makes Linux enormously more robust. There is no single point of failure and if some program's defaults get corrupted, it's trivial to fix and trivial to tell users how to fix it ("rm .foobar" and you should be fine).
That may or may not be true. It would mean that you can't use the same contract text for your own contracts. However, aggregation and publishing of EULAs for legal analysis seems like it ought to fall under "fair use".
And stealing IP from lawyers is just asking for trouble.
It's not "stealing" if it falls under "fair use".
I suspect that physical rental of the ROMs would be OK (even if people copy them); that's the same with other digital medial like CDs, DVDs, and game cartridges.
I don't think anybody can say for certain how it would be for electronic rentals of ROMs. I think for e-books there was a lot of wrestling over the issue of electronic rentals over the last few years, and one way or another, it doesn't seem to have become widespread (yet?). Maybe someone knows whether that issue was settled at least legally.
I don't see why. Instruction sets don't generally seem to be protected by any law. Otherwise, AMD would have had to license the x86 instruction set, which I doubt they did (and if they did, Intel would be in a great negotiating position). Or the various IBM, PDP, and VAX clones would have had to license the respective instruction sets, which, again, doesn't seem to have been the case.
In fact, in their own article on the Transmeta use of x86-64, which they reference, they wrote:
Seems to me that the "Inquirer" agrees that x86-64 doesn't require a formal license.
I don't particularly like the x86 instruction set, but unless we all switch to Alpha or SPARC, x86-64 makes the most sense to me.
Commercial rental of copyrighted works is governed by its own set of rules. Libraries and some other institutions are special. Perhaps this would work if it falls under fair use, but then you may not have to worry about "lending" anyway.
Oh, yes, it is. If I want to produce content that can play on a device that only plays content under DRM, I have to sign it with whatever signatures that DRM device expects. And if those devices are made according to the specs of a small consortium of large manufacturers that only let their own content be played on those devices (or charges steep fees to independent producers), I can't distribute my own content to play on those devices.
That's pretty straightforward and even if it perhaps is draconian, it's still only punishing something that's already illegal and that you shouldn't be doing.
If it were already covered by copyright law, then they wouldn't need this legislation. No, this is a set of new rights for things that are currently probably still permissible.
And it's deliberate: a few, powerful, big companies with lots of money and lots of influence think they can monopolize the market. In fact, for CDs and DVDs, that kind of worked--for a while. This new effort won't really work in the long run either, but it could be painful in the short run. And it could be painful for the stockholders in those big companies that don't have a better business plan than to screw their customers.
Think about it this way: each consumer has some amount they are willing to pay for entertainment per month--the pie doesn't get any larger. Companies that have lower costs, lower prices, and satisfy consumers more will get that entertainment dollar. Do you really think complex DRM schemes are going to lead to usable and inexpensive devices and content?
What's going to win out in the long run is either no DRM at all or devices that anybody can author to; there won't be any need to imitate Microsoft's or anybody else's signatures. That, or people will just go back to small, live performances. In any case, the big media companies pushing for this are going to lose out. They had a golden era with vinyl and CDs, where they could mass-produce cheaply but consumers couldn't replicate, and there was no alternative or competition. That's over now.
Nevertheless, while it just delays the inevitable, it is disappointing that politicians don't get this. And it is particularly disappointing that some politicians are so much in the pocket of vested interests that they try to push through such legislation without much debate.
We, the people, have the right to decide what we protect under copyright and what falls under fair use.
Analogies between "intellectual property" and physical property are self-serving and legally inaccurate for the most part. People who say that "piracy is OK" have already given into the mindset. No, piracy is not OK, but copying should not and does not constitute "piracy" under many circumstances.
If junior open source programmers can "run out and clone the project", then obviously "the project" can't be very big or complicated. If it weren't the "junior open source programmers" that clone it, it would be a competitor, or some other open source project. Perhaps the business management of the project should take then hint and look for a more profitable project.
just a minority are fanaticals but you put yourself in risk hiring people with a open source background.
Yes, you do put yourself at risk: at risk that if you persist in doing something stupid, your programmers are going to run out on you. I'd consider that a benefit. But to each their own.
(smoothwall for example, there are countless of other examples).
Was there actually a company stupid enough trying to make a business out of that?
I've been using it with 2.4.18, and it's been working just fine (I have a USB 2.0 disk). The interface cards are cheap and the throughput is great. And it seems to be a simple extension of USB 1.0, so drivers like USB storage just seem to work. (Firewire, of course, works as well.)
Just to be clear: you can, of course, initialize a reference in an object. That is as problematic as pointers, and I avoid it.
C and C++ use the term "pointer" for a lot of things. It is the totality of those things, and the fact that they are all the same datatype, that presents problems.
"Not using pointers" means not using the stuff that is specific to pointers in C/C++: pointers into the middle of arrays, pointer arithmetic, pointers to local variables. Things would be a lot less problematic if "pointer into the middle of an array", "pointer to local variable", "pointer to heap-allocated object", etc., all had different types.
References are not "pointers": you can't do arithmetic on them, you can't store them in data structures, etc., many of the things that cause problems. But even unrestricted use of references is problematic and error prone in C++, and it is best to limit oneself mostly to references to variables passed as function arguments.
You're not particularly creative with pointers, if you honestly believe they can be replaced by arrays.
I am decidedly not creative with pointers. I used to be very creative with pointers, but I found that hand-crafted pointer code that looked "efficient" didn't run any faster on modern hardware and was a lot harder to debug.