``Ya, that's pretty much why I can't stand him. He talks about freedom, but wants to dictate how I, as a developer, can market or sell the product of my effort.''
Not "market or sell", but yes, copyleft is about limiting what you, as a developer, can do. That's because it's about the rights of _users_, not developers. Remember, the developer is the company that will take your work, charge an arm and a leg for it, and sue if you don't abide by their terms. The user is you, trying to get your printer to work.
``The Linux community would undoubtedly prefer a free software version of the Flash player. However, it is unlikely to be produced by Adobe, since the Flash software business model is based on selling server products: the server and development software. Providing a free implementation of the client would probably result in competition for those products that would result in less revenue for Adobe.''
Something isn't quite right with your reasoning there. If the first part of what you say is true, and Adobe's business model is based on selling server products, then they would win by having the client as widely deployed as possible and lowering the client development costs as much as possible. Both of these can be achieved by making the client open source. By keeping it closed source, they have to fund all the development themselves, which increases their cost and (in practice) limits the presence of the client.
``I was one of many that put my name to asking for a 64 bit version. Now if only there was a 64 bit Skype and that ever elusive 64 bit browser plug-in for the 64 bit Sun Java.''
If these had been open source, there would probably have been stable and full-featured 64-bit versions for some time now.
Normally I would agree with you that if you buy a bad product, it's not somebody else's fault. But in this case, customers were being misled into thinking that a certain computer would be adequate for running Vista, whereas, really, that wasn't the case. If you actually made your purchase decision based on this misleading message, I think it is reasonable to blame whoever did the misleading.
How do you mean? They money is lost to the woman who gave it away, true, but it's still somewhere. What do you know, perhaps it's now working to improve the lives of poor africans who weren't fortunate enough to be born in a prosperous country.
Re:WTF? If AMD64 can't do it with a full x86 core.
on
Ubuntu Ports To ARM
·
· Score: 1
The only reason x86 has a software advantage is that it runs Windows (and DOS). Linux and others have been made to run on anything from bicycle shoe strings to galactic overlords, but if you want to run (desktop) Windows, x86 is pretty much your only choice.
> > Could you have imagined Obama saying that during the election? > No... but he just went up in my estimation having read that.
As he did in mine. On the other hand, I hope he does realize that, although him changing light bulbs does not _solve_ the problem, it does _help_. And it's things that help that will eventually solve the problem. There's no magic bullet that is going to completely solve everything all at once. We solve the problem by doing the little things that bring us closer to the solution, until, one day, we find the problem is gone.
``As a hardware OEM, you would have to be thinking that it is going to cost you way, way less to get a working driver for your new product written for Linux.''
Well, yes. But there's the benefit side of the equation to consider, too. What matters is not so much how much it costs as how much you will profit from it. Getting a Linux driver written costs you whatever costs you incur for getting the information out there and answering questions driver writers have. It will definitely get you sales. Say, 5 million.
Getting a Windows driver written will cost you about the same. Except it's unlikely that someone will do it for free. So you'll have to pay someone to do it. This is your extra cost. But then, you get more sales. Maybe 100 million.
I think the larger number of sales dwarfs any cost savings here.
On the other hand, here's something to consider:
- Clearly, the worst case is writing the Linux driver yourself. You'll be paying for work that someone could (and probably would) have done for free (and, if results from the past are any indication, would probably have done better).
- Since the work you need to do to get someone else to write a Linux driver for you is largely the same as the work you need to do to get someone to write a Windows driver for you (employed by you or not), developing a Windows driver and letting someone develop a Linux driver costs little extra than only developing a Windows driver. You can get extra sales almost for free!
I don't understand. We _do_ have filesystems (JFFS, JFFS2, YAFFSLogFS) that are tailor-made for Flash devices.
Did you mean we might have _Windows_ supporting filesystems tailor-made for Flash? Well...I think the reason we don't isn't so much that existing filesystems work "well enough", but more that it takes Microsoft a long time to catch up with the world. How many years of widespread 32-bit CPUs did it take them to produce a 32-bit OS? How many years of widespread Internet access to produce an OS that wouldn't be corrupted and taken over within an hour of being connected to it? And that's assuming they even want to do it at all. They can't cater to all markets, and neither should they want to. They are a for-profit company; if they don't see the business case, why would they do the work?
I'll let you decide which is better, but this is the difference:
detach, as the name implies, detaches the command it runs from the shell and the terminal. There really won't be any association between them anymore. If you close the shell, your command won't receive a SIGHUP.
nohup sets the signal mask for your command so that SIGHUP is ignored, and redirects output to nohup.out. Other than that, it is just a normal command run under the shell. It's listed in jobs. It will also receive SIGHUP when your shell closes.
I'll be honest: I wrote detach because I hadn't discovered any of the alternatives that are listed on its webpage. But there's a reason I hadn't discovered them: they don't do the same thing detach does, and therefore didn't have the keywords I searched for listed with them.
What detach does, really, is to make sure that some program is running, much like the daemons that you will typically find running on a *nix system. In fact, it uses the same mechanism that most if not all daemons use. That is exactly what it does. None of the alternatives I have found do exactly that.
Of all the alternatives I have found, disown comes closest to doing the same thing as detach. Perhaps the end result is actually exactly the same (unlike with nohup); I don't know that for sure. But (1) disown is a builtin in some shells, not a command that can be used from all shells, like detach, and (2) you run disown _after_ starting the command...I, and various other users, find it more natural to type "detach command args" than to type "command args & disown", but that may be a matter of preference.
Finally, I don't like nohup, because it goes and creates files with fixed names (in particular, nohup.out). So even in situations where I could use it, I would prefer detach.
I hope that this clears things up a little. Also see the detach webpage. It lists some possible alternatives and explains how they differ from detach.
Note that I am the author of detach, so of course all of this is fueled by a desire to not have my baby be a useless imitation of some already existing command.;-) But seriously, I really feel detach does exactly what I want and the others don't. Having said that, the reason I listed the alternatives is so that people can use those if they fit their needs, without having to go through the hassle of downloading, compiling, and installing detach. It's not packaged for any distros I'm aware of (I used to provide Debian packages and OpenBSD ports, but I just don't have the time anymore).
Note that detach isn't dtach. detach detaches the program it starts from the terminal. dtach creates a virtual terminal and attaches the program to that, instead of to the terminal dtach was run from. You can then attach and detach from that virtual terminal (although, unlike with screen, dtach doesn't remember previous output from the command).
dtach and screen are for commands that produce output, where you want to go away and come back to see the output at some point, and for interactive commands, where you have to produce input.
detach is for things like daemons and X clients, where you aren't interested in looking at the output. If you want, you can redirect the output to a file. You can also provide a file to be used as input, but you can't interact with the program yourself. The program really is detached from the terminal.
detach. Start programs and then just forget about them while they keep running. You'll get your prompt back and the program will just keep running in the background, even when you exit the shell you started it from.
Re:I haven't followed the whole Android business,
on
T-Mobile G1 Rooted
·
· Score: 1
``...wasn't this supposed to be an open platform anyway? I don't quite get it.''
As far as I know, it wasn't really. That's what they are screaming from the rooftops, but really, the only thing you get access to is Java. That's nothing worth getting excited about. Now, if this "exploit" actually allows you access to the *nix system, that's a whole different story. So maybe someone can shed some light on whether it does that or not.
``Once a free codec becomes widely adopted the chance of some proprietary codec coming along afterwards is near zero.''
You mean like WMA, MP3Pro, AAC, and Talad knows what else coming along after Ogg Vorbis?
``No one will pay h264 licensing costs when quality free alternatives are vibrant.''
You mean like people _paying_ to be allowed to add support for MP3, WMA (and PlaysForSure) and AAC (and FairPlay) to their players, but not supporting the free Ogg Vorbis?
I am sorry to say it, but I think history contradicts your optimism.
There already is one API to program against if you're a hardware developer who wishes to support Linux. It's called Linux, and it's used by all Linux distributions.
If you are software developer, there are a number of APIs you can choose from that will work across all reasonable Linux distributions.
Really, doing cross-distro work isn't that hard.
What is hard is making your software work on any Linux distro at all if you're going about it the wrong way. Linux isn't about ABI stability, and, with the plethora of different library versions out there that change during upgrades, neither is the userland. The only way to make your software work across different versions and/or different distros is to allow people to compile the code themselves, at least the part of the code that interacts with the operating system. But once you've done that, all the work of compiling and integrating with the plethora of different distros out there can be done by others, and will be if they value your software enough. You don't have to worry about that.
``Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux''
Don't forget that Linux is not the only game in town. X.org suppors Linux, but it also supports FreeBSD, NetBSD, OpenBSD, Solaris, UnixWare, LynxOS and HURD. I think there are actually more, but those are the ones listed in the manpage.
If we do as you propose and make the operating system kernel supply the drivers, drivers would have to be written for all those 7 kernels, instead of just once for X.org. What we have now is exactly how I like things to be: a common driver API across operating systems, so that drivers need be written only once.
Actually, my number one gripe with OpenBSD is the time involved in keeping the whole system up to date. It's great that they audit the whole base system and manage to deliver a very secure operating system (written in C, of all languages!) which nevertheless has all or most of the familiar Unix APIs, but I have to wonder what happens to that security once you install ports and keep the system running for a while. The ports aren't subject to the same security auditing as the base system, neither the base system nor the ports are updated regularly, and when they are, upgrading definitely isn't as fast and simple as apt-get dist-upgrade.
At some point I had to wonder if the OpenBSD systems I ran but rarely updated (because it would have to be done by hand) were really more secure than the Debian systems I ran that might have started with many more vulnerabilities, but that were kept up to date. There is really no way to know, but, in the end, I decided that OpenBSD wasn't worth all the effort it cost me if I couldn't convince myself that it really ended up being more secure. That and the fact that all my efforts to contribute had been rejected (politely, I might add) made me decide to abandon OpenBSD and use Debian everywhere. I only wish Debian used stack smashing protection and PaX.
Yes. But that is true in any case, of course. The base case is that you have to sign up for every service, and have to remember a separate set of authentication credentials for each of them. With OpenID, that changes to having to sign up for every service, but only having to remember a single set of authentication credentials for all of them that support OpenID, falling back to the base case for the others. The burden on the user is actually less.
``I can imagine that most people don't even want to bother.''
I can imagine that, too. But that doesn't mean anything is wrong with OpenID. Yes, there is some resistance to overcome, and many people will not take that step, even if it would make them more efficient if they did. This happens all the time. It doesn't mean the step is not worth it, it just means that people make choices that don't yield optimal results.
``That's true in an isolated case, but we live in a world where email addresses and phone numbers are common, and OpenID URLs are not. This makes it easier for people to deal with email addresses and phone numbers, simply because they're more used to it.''
I disagree. We live in a world where phone numbers, email addresses, and URLs are all common, and most people remember very few, if any, of each. They just record them somewhere. People could remember their own phone number, but they don't have to, and many people don't. Similarly, people could remember their own OpenID identifier, but they don't have to. After all, the OpenID identifier isn't a secret. You can just record it somewhere, just like you could your phone number, email address, etc.
Slashdot Mirror
``Ya, that's pretty much why I can't stand him. He talks about freedom, but wants to dictate how I, as a developer, can market or sell the product of my effort.''
Not "market or sell", but yes, copyleft is about limiting what you, as a developer, can do. That's because it's about the rights of _users_, not developers. Remember, the developer is the company that will take your work, charge an arm and a leg for it, and sue if you don't abide by their terms. The user is you, trying to get your printer to work.
``The Linux community would undoubtedly prefer a free software version of the Flash player. However, it is unlikely to be produced by Adobe, since the Flash software business model is based on selling server products: the server and development software. Providing a free implementation of the client would probably result in competition for those products that would result in less revenue for Adobe.''
Something isn't quite right with your reasoning there. If the first part of what you say is true, and Adobe's business model is based on selling server products, then they would win by having the client as widely deployed as possible and lowering the client development costs as much as possible. Both of these can be achieved by making the client open source. By keeping it closed source, they have to fund all the development themselves, which increases their cost and (in practice) limits the presence of the client.
``I was one of many that put my name to asking for a 64 bit version. Now if only there was a 64 bit Skype and that ever elusive 64 bit browser plug-in for the 64 bit Sun Java.''
If these had been open source, there would probably have been stable and full-featured 64-bit versions for some time now.
Are there text versions of the interviews available, too?
Imagine a Beowulf cluster of these!
"Done for" in what sense? Just because someone else gets it better doesn't mean you get it worse.
Normally I would agree with you that if you buy a bad product, it's not somebody else's fault. But in this case, customers were being misled into thinking that a certain computer would be adequate for running Vista, whereas, really, that wasn't the case. If you actually made your purchase decision based on this misleading message, I think it is reasonable to blame whoever did the misleading.
``It's wrong that she basically destroyed the financial security of her husband as well.''
Exactly. If everybody tells you it's a scam, the very least you can do is have the decency not to throw money that isn't yours at it!
``But no, it was squandered away.''
How do you mean? They money is lost to the woman who gave it away, true, but it's still somewhere. What do you know, perhaps it's now working to improve the lives of poor africans who weren't fortunate enough to be born in a prosperous country.
The only reason x86 has a software advantage is that it runs Windows (and DOS). Linux and others have been made to run on anything from bicycle shoe strings to galactic overlords, but if you want to run (desktop) Windows, x86 is pretty much your only choice.
> > Could you have imagined Obama saying that during the election?
> No... but he just went up in my estimation having read that.
As he did in mine. On the other hand, I hope he does realize that, although him changing light bulbs does not _solve_ the problem, it does _help_. And it's things that help that will eventually solve the problem. There's no magic bullet that is going to completely solve everything all at once. We solve the problem by doing the little things that bring us closer to the solution, until, one day, we find the problem is gone.
``As a hardware OEM, you would have to be thinking that it is going to cost you way, way less to get a working driver for your new product written for Linux.''
Well, yes. But there's the benefit side of the equation to consider, too. What matters is not so much how much it costs as how much you will profit from it. Getting a Linux driver written costs you whatever costs you incur for getting the information out there and answering questions driver writers have. It will definitely get you sales. Say, 5 million.
Getting a Windows driver written will cost you about the same. Except it's unlikely that someone will do it for free. So you'll have to pay someone to do it. This is your extra cost. But then, you get more sales. Maybe 100 million.
I think the larger number of sales dwarfs any cost savings here.
On the other hand, here's something to consider:
- Clearly, the worst case is writing the Linux driver yourself. You'll be paying for work that someone could (and probably would) have done for free (and, if results from the past are any indication, would probably have done better).
- Since the work you need to do to get someone else to write a Linux driver for you is largely the same as the work you need to do to get someone to write a Windows driver for you (employed by you or not), developing a Windows driver and letting someone develop a Linux driver costs little extra than only developing a Windows driver. You can get extra sales almost for free!
I don't understand. We _do_ have filesystems (JFFS, JFFS2, YAFFS LogFS) that are tailor-made for Flash devices.
Did you mean we might have _Windows_ supporting filesystems tailor-made for Flash? Well...I think the reason we don't isn't so much that existing filesystems work "well enough", but more that it takes Microsoft a long time to catch up with the world. How many years of widespread 32-bit CPUs did it take them to produce a 32-bit OS? How many years of widespread Internet access to produce an OS that wouldn't be corrupted and taken over within an hour of being connected to it? And that's assuming they even want to do it at all. They can't cater to all markets, and neither should they want to. They are a for-profit company; if they don't see the business case, why would they do the work?
I'll let you decide which is better, but this is the difference:
detach, as the name implies, detaches the command it runs from the shell and the terminal. There really won't be any association between them anymore. If you close the shell, your command won't receive a SIGHUP.
nohup sets the signal mask for your command so that SIGHUP is ignored, and redirects output to nohup.out. Other than that, it is just a normal command run under the shell. It's listed in jobs. It will also receive SIGHUP when your shell closes.
I'll be honest: I wrote detach because I hadn't discovered any of the alternatives that are listed on its webpage. But there's a reason I hadn't discovered them: they don't do the same thing detach does, and therefore didn't have the keywords I searched for listed with them.
What detach does, really, is to make sure that some program is running, much like the daemons that you will typically find running on a *nix system. In fact, it uses the same mechanism that most if not all daemons use. That is exactly what it does. None of the alternatives I have found do exactly that.
Of all the alternatives I have found, disown comes closest to doing the same thing as detach. Perhaps the end result is actually exactly the same (unlike with nohup); I don't know that for sure. But (1) disown is a builtin in some shells, not a command that can be used from all shells, like detach, and (2) you run disown _after_ starting the command...I, and various other users, find it more natural to type "detach command args" than to type "command args & disown", but that may be a matter of preference.
Finally, I don't like nohup, because it goes and creates files with fixed names (in particular, nohup.out). So even in situations where I could use it, I would prefer detach.
I hope that this clears things up a little. Also see the detach webpage. It lists some possible alternatives and explains how they differ from detach.
Note that I am the author of detach, so of course all of this is fueled by a desire to not have my baby be a useless imitation of some already existing command. ;-) But seriously, I really feel detach does exactly what I want and the others don't. Having said that, the reason I listed the alternatives is so that people can use those if they fit their needs, without having to go through the hassle of downloading, compiling, and installing detach. It's not packaged for any distros I'm aware of (I used to provide Debian packages and OpenBSD ports, but I just don't have the time anymore).
Note that detach isn't dtach. detach detaches the program it starts from the terminal. dtach creates a virtual terminal and attaches the program to that, instead of to the terminal dtach was run from. You can then attach and detach from that virtual terminal (although, unlike with screen, dtach doesn't remember previous output from the command).
dtach and screen are for commands that produce output, where you want to go away and come back to see the output at some point, and for interactive commands, where you have to produce input.
detach is for things like daemons and X clients, where you aren't interested in looking at the output. If you want, you can redirect the output to a file. You can also provide a file to be used as input, but you can't interact with the program yourself. The program really is detached from the terminal.
detach. Start programs and then just forget about them while they keep running. You'll get your prompt back and the program will just keep running in the background, even when you exit the shell you started it from.
``...wasn't this supposed to be an open platform anyway? I don't quite get it.''
As far as I know, it wasn't really. That's what they are screaming from the rooftops, but really, the only thing you get access to is Java. That's nothing worth getting excited about. Now, if this "exploit" actually allows you access to the *nix system, that's a whole different story. So maybe someone can shed some light on whether it does that or not.
``Once a free codec becomes widely adopted the chance of some proprietary codec coming along afterwards is near zero.''
You mean like WMA, MP3Pro, AAC, and Talad knows what else coming along after Ogg Vorbis?
``No one will pay h264 licensing costs when quality free alternatives are vibrant.''
You mean like people _paying_ to be allowed to add support for MP3, WMA (and PlaysForSure) and AAC (and FairPlay) to their players, but not supporting the free Ogg Vorbis?
I am sorry to say it, but I think history contradicts your optimism.
There already is one API to program against if you're a hardware developer who wishes to support Linux. It's called Linux, and it's used by all Linux distributions.
If you are software developer, there are a number of APIs you can choose from that will work across all reasonable Linux distributions.
Really, doing cross-distro work isn't that hard.
What is hard is making your software work on any Linux distro at all if you're going about it the wrong way. Linux isn't about ABI stability, and, with the plethora of different library versions out there that change during upgrades, neither is the userland. The only way to make your software work across different versions and/or different distros is to allow people to compile the code themselves, at least the part of the code that interacts with the operating system. But once you've done that, all the work of compiling and integrating with the plethora of different distros out there can be done by others, and will be if they value your software enough. You don't have to worry about that.
``Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux''
Don't forget that Linux is not the only game in town. X.org suppors Linux, but it also supports FreeBSD, NetBSD, OpenBSD, Solaris, UnixWare, LynxOS and HURD. I think there are actually more, but those are the ones listed in the manpage.
If we do as you propose and make the operating system kernel supply the drivers, drivers would have to be written for all those 7 kernels, instead of just once for X.org. What we have now is exactly how I like things to be: a common driver API across operating systems, so that drivers need be written only once.
Actually, my number one gripe with OpenBSD is the time involved in keeping the whole system up to date. It's great that they audit the whole base system and manage to deliver a very secure operating system (written in C, of all languages!) which nevertheless has all or most of the familiar Unix APIs, but I have to wonder what happens to that security once you install ports and keep the system running for a while. The ports aren't subject to the same security auditing as the base system, neither the base system nor the ports are updated regularly, and when they are, upgrading definitely isn't as fast and simple as apt-get dist-upgrade.
At some point I had to wonder if the OpenBSD systems I ran but rarely updated (because it would have to be done by hand) were really more secure than the Debian systems I ran that might have started with many more vulnerabilities, but that were kept up to date. There is really no way to know, but, in the end, I decided that OpenBSD wasn't worth all the effort it cost me if I couldn't convince myself that it really ended up being more secure. That and the fact that all my efforts to contribute had been rejected (politely, I might add) made me decide to abandon OpenBSD and use Debian everywhere. I only wish Debian used stack smashing protection and PaX.
In the Netherlands, some mobile phone network operators have been offering free PCs and laptops with their subscriptions for years.
``I think we can all agree, 256 cores is enough for anybody''
No. Why would that be enough? I can think of many scenarios where more cores would be useful, and computers with more cores have already been built.
``Agreed. Only one problem: one has to sign up!''
Yes. But that is true in any case, of course. The base case is that you have to sign up for every service, and have to remember a separate set of authentication credentials for each of them. With OpenID, that changes to having to sign up for every service, but only having to remember a single set of authentication credentials for all of them that support OpenID, falling back to the base case for the others. The burden on the user is actually less.
``I can imagine that most people don't even want to bother.''
I can imagine that, too. But that doesn't mean anything is wrong with OpenID. Yes, there is some resistance to overcome, and many people will not take that step, even if it would make them more efficient if they did. This happens all the time. It doesn't mean the step is not worth it, it just means that people make choices that don't yield optimal results.
``That's true in an isolated case, but we live in a world where email addresses and phone numbers are common, and OpenID URLs are not. This makes it easier for people to deal with email addresses and phone numbers, simply because they're more used to it.''
I disagree. We live in a world where phone numbers, email addresses, and URLs are all common, and most people remember very few, if any, of each. They just record them somewhere. People could remember their own phone number, but they don't have to, and many people don't. Similarly, people could remember their own OpenID identifier, but they don't have to. After all, the OpenID identifier isn't a secret. You can just record it somewhere, just like you could your phone number, email address, etc.
``This is the first "publically-visible" sign of their slide into Microsoft-like evilness''
Not even close. They have been doing much more questionable things for a long time now.