Agreed, it is bribery. But it wouldn't be a problem if we all had the same amount of money to give. If we did, it would be ridiculous to call it bribery. But we don't, so it is a problem. The wealthy can give more than the poor, much more. So much more that the poor, despite their number cease to matter.
This is not how a democracy should work as it utterly breaks it in favour of the wealthy few. I don't understand how ScentCone can possibly think it's ok and get score:5 Insightful!
LOL! You think?
If you don't want graphics, yes sure, chroot Debian like I have now.
If you want graphics it's xvfb and vnc, shudder.
Replace the OS all together? Good luck with that, there is binary blobs drivers to contend with.
There is no reason at all they couldn't have provided at least a skeleton of a normal graphical Unix. A modern smart phone has crazy spec from the future compared with what was around when Unix graphical standards where laid down.
Why the hell should I have to port cross platform stuff to Android?
If they hate X, help with Wayland. If users want normal graphical Unix, we can at least install the Wayland X server.
My brother told me of a story (year or two ago) where he downloaded pirate version of a game he has bought because the DRM failed to allow him to play the game. The pirate version worked fine....
You also missing the point. DRM only need to be broken by one smart person, then everyone just copies the unprotected copy. You don't have to be the one to crack it to get a copy.
chroot Debian on my Android was never satisfactory. I want a standard Linux phone, ideally Debian based. Yes I know, the N900, but it is too old and a dead end. I'm no fan of Unity and modern Ubuntu, but maybe on a phone, it'll win me over. Very interesting. Also, more competition is always good.:-)
"Until the engineers get a clue, open source projects will never be more than a closet of hobbyist projects."
What world are you living in? Even if you think everything you run is closed (and it probably isn't), there is a massive sea of things running free software, not just open source, that you will interactive with everyday. It's not unlikely you own a few. There are plenty of big companies and government departments that even the Linux desktop is used. Wake up. It's everywhere already.
I've did a compete namespace and had the same issues. MS only documented at all after being taken to court by the EU. The docs are barely enough and new interfaces have been added since XP, and not all of them documented. Many don't even have a name you can get at, let alone a interface definition, just a GUID. Some, others have worked out, some, no one outside Microsoft knows.
My eyes are now open to this crap way of working. The "magic blackbox" thinkings are naive if they think documenting the surface of the blackboxs are enough. The more complex the thing, the less well documentation is going to be able to cover all the combinations. I'm not saying source instead of docs, I'm saying source as a fall back for when the docs are not enough.
You missed the point. You can have implementations doing exactly what the standard says but unable to work together because of a whole in the docs. Unix systems have the advantage that much of them are open, avoiding problems as implementations can look at what each other do. Also there is almost always multiple implementations so problems show up quickly. In Windows world you have the worse case, one, closed implementation. Any other later implementation has to use that as a reference implementation. When the docs fail, you have to find exactly what that implementation does and do the same, or at least what is compilable. Worse, if the docs say one thing and the closed reference implementation does another, you must do what the closed implementation does. Worse still, Microsoft have a history of deliberately making life for other implementations even harder. It's a nightmare situation. It's why I feel pushing Wine and Mono as things that make Microsoft technology cross platform is stupid. It's a game you can not win or even draw.
Docs aren't perfect. We all know this. To me, if there isn't a open reference implementation I'm not sure it's a open. Only an implementation covers everything required. Yes, in theory, the docs should be an implementation written in English, but that fails as it can't be run and tested, so it's always an incomplete implementation. Also, personally, I often find it easier to dig out exact details for code from other code, rather than from written English.
Yer, only if the specification is perfect. Which it never is. There is always things not documented that projects like Wine, Mono, Samba, etc must work out.
Most of the time I don't think it's a deliberate MS policy (though I bet some of the time it is), it's just the nature of software. Really you want not just a published specification but a open reference implementation. MS, intentionally or otherwise, use this in both directions. http://tuxdeluxe.org/node/296
Your right, I don't develop with cygwin. I just use it as a user. Anything I install, I install from it's repositories, and so far, it's always worked fine. I have compiled one or two things with it, and that's all just worked like it was a real Unix. This doesn't negate what you are saying, but I'm using it as an isolated environment and not trying to redistribute anything. If I did, I would try to redistrubute through the package management system, so may not hit the issues you have. But perhaps the repositories aren't controled like real Unix ones and I've just been lucky, I've not looked.
I've not found speed an issue for my uses.
I use the Unix like environment because I prefer it (and it has history longer than that session), but the standard console (Window's running cygwin) is terrible. MinTTY is amazing when compared with the standard console. So am I going to use PuTTY to connect to a real Unix environment? No. I'm going to use normal ssh like I was on a Unix environment. I did use PuTTY and normal Windows userland for quite a while, but I found cygwin + MinTTY works best for me. The piping stuff is an example where I can forget I'm on Windows and just do as I would normally. Don't get me wrong, I use PuTTY when on other people's machines, or don't have admin, but if it's a Windows machine that's for me, I'm going to setup and use MinTTY + cygwin because it gives me more than PuTTY.
I just wish it's package management was more like APT. I miss apt-get when on cygwin.
I didn't know Powershell still uses the crap default terminal!
Haven't gone near it as I'm happy with cygwin and MinTTY, plus I try and avoid Windows specific stuff.
That is how I do still use PuTTY from time to time. When it's not your machine, it's polite to only use PuTTY rather than install anything, and if you don't have admin, it's the only option. But I don't often do this, I use cygwin+mintty as preference, like on my work machine.
I find the PuTTY terminal isn't much better. Mintty is the best I found for Windows. Shame it's not like Guake, but stuff I found to do that on Windows hasn't been functional.
Much nicer console and gives just standard command line ssh, which is all I want/need. I stopped using Putty years ago...
During the heavy snow in the UK, I was regularly checking how bad it was at home with:
That's the old JIT argument, and while in theory it might have some merit, in the last decade it shown not to. Christ, a great deal of stuff still targets i386 just to ensure it runs on everything, and yet those apps still out perform Java/C# apps. Why? Because the core instructions are still the core instructions and the old RISC rule holds true, most of the work is done using a few key instructions. Plus where the JIT argument breaks down is with things like DLLs. The DLL can be very specific for the computer, and old applications link in that DLL to do the work, and thus the work in question for the old application is done with the latest, computer specific, stuff. If you want speed, use pre-canned stuff, if you want productivity use something like python, if you want both, probably best use a language for each. For instance core logic in C, and GUI stuff in python. Or use C++ and except the complexity that adds. If you want to have both but are willy to compromise to have both, then maybe that is where JIT languages come in.
In Debian (and no doubt other package managers) you can have A and B use different versions of a shared lib, but one uses the "somelib.so" and the other "somelib.1.0.so". Normally a version of lib is standardize as the version of a lib. Other versions are used with version number as part of the name. If there is a conflict, then yes you can have only one or the other, but I don't see how you get out of that. For instance/usr/bin/convert and/usr/local/bin/convert is still a conflict in my book, one (local) overrides the other even if it's not overwritten it. You could hack something up with chroot, but it all starts getting ugly. Unless I'm missing something of course.
I grew up as a RiscOS user, which had this kind of application folder system.
Package management is >much
If you are going to have shared blobs of code like shared-objects/DLL you need package management, end of story.
You want one copy of each, or a least one of each version, and you want to update that one file. Even on modern machines, you don't want to statically link everything, even if you did, think about updates. If one of these files need a fix, it's much easier to update that one file, then update every program built statically against it. Use version number as part of the filename and have a sym link without the version number to the latest version. If something needs a specific version, it can be built to link to that not the latest. You can do as many version levels of this as required. Seriously, this is much better centrally managed and updated. You can even list all applications that use the file, even before anything is installed. I wouldn't go back to an application folder system if you paid me to. Windows has some central management with the manifest stuff and add/remove programs, but compared with Debian package management, it's an over-complex mess or a fraction of the power. Other package manager might be as good as Debian's, but so far, none have impressed me as much.
There is a sweet spot though isn't there. Assembler is slow to develop in, but very fast. C can be used almost as a high level assembler, you can be pretty clear about how you want things to compile, yet C is much faster to develop in than assembler. Some languages (say python) are very quick to develop in, but if you care about speed at all, are the wrong choice. I would say C and C++ are the sweet spot where you get most bang for bucks in terms of speed cost and productivity gain. Afterwards, it does seam like diminishing returns, you pay more and more performance, for less and less productivity gain. Assembler to C is the biggest jump at the smallest cost.
Memory is used, even if no application is using it. It's used to cache disk. Free memory is not wasted memory. Bloat is a relative term. If one application, with feature parity with another, uses much less memory than the other, it makes the other seam bloated. If Unity is using much more memory than Gnome3, as there is feature parity, then Gnome3 is bloated. It's an arms race we all win from because our computers get faster for free.:-)
This is why MS are pushing.NET, moves them away from being in a death embrace with x86 (that and it gives a complete platform to lock people into).
I see byte code as a way closed source code can get the "run on anything" of open source, without opening the source.
With open source, you just compile it on the platform in question (ok it is more than that, but can be that).
If you have the source, and it's in the repository specific for a processor (and why not, not that many types of processors), why not just compile to native rather than a byte code indirection?
Thing is about this is that Windows was a slow and fat platform when it was native.... How is it going to compete on ARM when it's byte coded too?
But key is, did it run x86 software faster? Running it through something like, FX!32, it would have to quite a bit faster than x86 to best x86 at x86.
So in affect, it was more expensive , slower, processor because all the apps where x86.
Slashdot Mirror
Agreed, it is bribery. But it wouldn't be a problem if we all had the same amount of money to give. If we did, it would be ridiculous to call it bribery. But we don't, so it is a problem. The wealthy can give more than the poor, much more. So much more that the poor, despite their number cease to matter.
This is not how a democracy should work as it utterly breaks it in favour of the wealthy few. I don't understand how ScentCone can possibly think it's ok and get score:5 Insightful!
LOL! You think?
If you don't want graphics, yes sure, chroot Debian like I have now.
If you want graphics it's xvfb and vnc, shudder.
Replace the OS all together? Good luck with that, there is binary blobs drivers to contend with.
There is no reason at all they couldn't have provided at least a skeleton of a normal graphical Unix. A modern smart phone has crazy spec from the future compared with what was around when Unix graphical standards where laid down.
Why the hell should I have to port cross platform stuff to Android?
If they hate X, help with Wayland. If users want normal graphical Unix, we can at least install the Wayland X server.
My brother told me of a story (year or two ago) where he downloaded pirate version of a game he has bought because the DRM failed to allow him to play the game. The pirate version worked fine....
You also missing the point. DRM only need to be broken by one smart person, then everyone just copies the unprotected copy. You don't have to be the one to crack it to get a copy.
chroot Debian on my Android was never satisfactory. I want a standard Linux phone, ideally Debian based. Yes I know, the N900, but it is too old and a dead end. I'm no fan of Unity and modern Ubuntu, but maybe on a phone, it'll win me over. Very interesting. Also, more competition is always good. :-)
"Until the engineers get a clue, open source projects will never be more than a closet of hobbyist projects."
What world are you living in? Even if you think everything you run is closed (and it probably isn't), there is a massive sea of things running free software, not just open source, that you will interactive with everyday. It's not unlikely you own a few. There are plenty of big companies and government departments that even the Linux desktop is used. Wake up. It's everywhere already.
I've did a compete namespace and had the same issues. MS only documented at all after being taken to court by the EU. The docs are barely enough and new interfaces have been added since XP, and not all of them documented. Many don't even have a name you can get at, let alone a interface definition, just a GUID. Some, others have worked out, some, no one outside Microsoft knows.
My eyes are now open to this crap way of working. The "magic blackbox" thinkings are naive if they think documenting the surface of the blackboxs are enough. The more complex the thing, the less well documentation is going to be able to cover all the combinations. I'm not saying source instead of docs, I'm saying source as a fall back for when the docs are not enough.
You missed the point. You can have implementations doing exactly what the standard says but unable to work together because of a whole in the docs. Unix systems have the advantage that much of them are open, avoiding problems as implementations can look at what each other do. Also there is almost always multiple implementations so problems show up quickly. In Windows world you have the worse case, one, closed implementation. Any other later implementation has to use that as a reference implementation. When the docs fail, you have to find exactly what that implementation does and do the same, or at least what is compilable. Worse, if the docs say one thing and the closed reference implementation does another, you must do what the closed implementation does. Worse still, Microsoft have a history of deliberately making life for other implementations even harder. It's a nightmare situation. It's why I feel pushing Wine and Mono as things that make Microsoft technology cross platform is stupid. It's a game you can not win or even draw.
Docs aren't perfect. We all know this. To me, if there isn't a open reference implementation I'm not sure it's a open. Only an implementation covers everything required. Yes, in theory, the docs should be an implementation written in English, but that fails as it can't be run and tested, so it's always an incomplete implementation. Also, personally, I often find it easier to dig out exact details for code from other code, rather than from written English.
Yer, only if the specification is perfect. Which it never is. There is always things not documented that projects like Wine, Mono, Samba, etc must work out. Most of the time I don't think it's a deliberate MS policy (though I bet some of the time it is), it's just the nature of software. Really you want not just a published specification but a open reference implementation. MS, intentionally or otherwise, use this in both directions.
http://tuxdeluxe.org/node/296
Your right, I don't develop with cygwin. I just use it as a user. Anything I install, I install from it's repositories, and so far, it's always worked fine. I have compiled one or two things with it, and that's all just worked like it was a real Unix. This doesn't negate what you are saying, but I'm using it as an isolated environment and not trying to redistribute anything. If I did, I would try to redistrubute through the package management system, so may not hit the issues you have. But perhaps the repositories aren't controled like real Unix ones and I've just been lucky, I've not looked.
I've not found speed an issue for my uses.
I use the Unix like environment because I prefer it (and it has history longer than that session), but the standard console (Window's running cygwin) is terrible. MinTTY is amazing when compared with the standard console. So am I going to use PuTTY to connect to a real Unix environment? No. I'm going to use normal ssh like I was on a Unix environment. I did use PuTTY and normal Windows userland for quite a while, but I found cygwin + MinTTY works best for me. The piping stuff is an example where I can forget I'm on Windows and just do as I would normally. Don't get me wrong, I use PuTTY when on other people's machines, or don't have admin, but if it's a Windows machine that's for me, I'm going to setup and use MinTTY + cygwin because it gives me more than PuTTY.
I just wish it's package management was more like APT. I miss apt-get when on cygwin.
Here here!
I didn't know Powershell still uses the crap default terminal!
Haven't gone near it as I'm happy with cygwin and MinTTY, plus I try and avoid Windows specific stuff.
Then those improvements make all the difference. Plus, you can use it to use normal ssh, normally.
That is how I do still use PuTTY from time to time. When it's not your machine, it's polite to only use PuTTY rather than install anything, and if you don't have admin, it's the only option. But I don't often do this, I use cygwin+mintty as preference, like on my work machine.
I find the PuTTY terminal isn't much better. Mintty is the best I found for Windows. Shame it's not like Guake, but stuff I found to do that on Windows hasn't been functional.
Much nicer console and gives just standard command line ssh, which is all I want/need. I stopped using Putty years ago...
/dev/video0 -f matroska pipe:" | ffplay pipe
During the heavy snow in the UK, I was regularly checking how bad it was at home with:
ssh user@server "ffmpeg -r 15 -f video4linux2 -i
Which is exactly what I would have done if my work machine was Linux not Windows. Guess it depends what you want a ssh client on Windows for.
You probably can get more out of it to because it's probably using softfp instead of hardfp. http://www.youtube.com/watch?v=qWUd4TAEqTM
Hehe, I take you know it was Linux having drivers that probably started this. :-)
MS probably hated all those Linux Kinect YouTube videos.
That's the old JIT argument, and while in theory it might have some merit, in the last decade it shown not to. Christ, a great deal of stuff still targets i386 just to ensure it runs on everything, and yet those apps still out perform Java/C# apps. Why? Because the core instructions are still the core instructions and the old RISC rule holds true, most of the work is done using a few key instructions. Plus where the JIT argument breaks down is with things like DLLs. The DLL can be very specific for the computer, and old applications link in that DLL to do the work, and thus the work in question for the old application is done with the latest, computer specific, stuff. If you want speed, use pre-canned stuff, if you want productivity use something like python, if you want both, probably best use a language for each. For instance core logic in C, and GUI stuff in python. Or use C++ and except the complexity that adds. If you want to have both but are willy to compromise to have both, then maybe that is where JIT languages come in.
In Debian (and no doubt other package managers) you can have A and B use different versions of a shared lib, but one uses the "somelib.so" and the other "somelib.1.0.so". Normally a version of lib is standardize as the version of a lib. Other versions are used with version number as part of the name. If there is a conflict, then yes you can have only one or the other, but I don't see how you get out of that. For instance /usr/bin/convert and /usr/local/bin/convert is still a conflict in my book, one (local) overrides the other even if it's not overwritten it. You could hack something up with chroot, but it all starts getting ugly. Unless I'm missing something of course.
I grew up as a RiscOS user, which had this kind of application folder system.
Package management is >much If you are going to have shared blobs of code like shared-objects/DLL you need package management, end of story.
You want one copy of each, or a least one of each version, and you want to update that one file. Even on modern machines, you don't want to statically link everything, even if you did, think about updates. If one of these files need a fix, it's much easier to update that one file, then update every program built statically against it. Use version number as part of the filename and have a sym link without the version number to the latest version. If something needs a specific version, it can be built to link to that not the latest. You can do as many version levels of this as required. Seriously, this is much better centrally managed and updated. You can even list all applications that use the file, even before anything is installed. I wouldn't go back to an application folder system if you paid me to. Windows has some central management with the manifest stuff and add/remove programs, but compared with Debian package management, it's an over-complex mess or a fraction of the power. Other package manager might be as good as Debian's, but so far, none have impressed me as much.
Don't disagree, but the difference in productivity for the loss of speed isn't as good as good as asm to C.
There is a sweet spot though isn't there. Assembler is slow to develop in, but very fast. C can be used almost as a high level assembler, you can be pretty clear about how you want things to compile, yet C is much faster to develop in than assembler. Some languages (say python) are very quick to develop in, but if you care about speed at all, are the wrong choice. I would say C and C++ are the sweet spot where you get most bang for bucks in terms of speed cost and productivity gain. Afterwards, it does seam like diminishing returns, you pay more and more performance, for less and less productivity gain. Assembler to C is the biggest jump at the smallest cost.
Memory is used, even if no application is using it. It's used to cache disk. Free memory is not wasted memory. Bloat is a relative term. If one application, with feature parity with another, uses much less memory than the other, it makes the other seam bloated. If Unity is using much more memory than Gnome3, as there is feature parity, then Gnome3 is bloated. It's an arms race we all win from because our computers get faster for free. :-)
This is why MS are pushing .NET, moves them away from being in a death embrace with x86 (that and it gives a complete platform to lock people into).
I see byte code as a way closed source code can get the "run on anything" of open source, without opening the source.
With open source, you just compile it on the platform in question (ok it is more than that, but can be that).
If you have the source, and it's in the repository specific for a processor (and why not, not that many types of processors), why not just compile to native rather than a byte code indirection?
Thing is about this is that Windows was a slow and fat platform when it was native.... How is it going to compete on ARM when it's byte coded too?
But key is, did it run x86 software faster? Running it through something like, FX!32, it would have to quite a bit faster than x86 to best x86 at x86. So in affect, it was more expensive , slower, processor because all the apps where x86.