Whenever these articles come up people make the same error in the comments. Dynamic range compression IS NOT data compression. If you apply dynamic range compression (so that the difference between the loudest sounds and quietest sounds is reduced and then amplified --- higher RMS amplitude --- louder) the music has no subtleties to be lost by compression. Find an original or remastered recording of a band from yesteryear that play complex, well recorded music (a lot of jazz or jazz-influenced bands fall into this category, Steely Dan are one of my favourites, there are plenty of others) and compress the track with MP3. Compare. There is generally a very audible difference. I have a couple of MP3 rips in my music collection which occasionally get played instead of the FLAC version; I can hear it straight away, the percussion generally sounds flat and muted, or symbols are very harsh.
Partially need, partially choice. 8 bits represents a useful amount of information --- it's enough to represent basic text with control characters. It's a power of two, and an 8 bit binary number can be represented by two complete hexadecimal digits (i.e. 0x00 -- 0xFF), and is a factor of other common integer sizes --- 32 bits is 4*8 bits.
In Unix if malloc returns null then the memory allocation failed and you don't have the memory. A well written program should check that. Overcommitting memory can have efficiency advantages, but things can also turn out badly. Linux has heuristics to determine how much to overcommit the memory, or it can be disabled entirely.
But if the cost of the engine license is about $100,000 (for example), that might pay for one supporting programmer for a year and a half. The support roles however are not just hand-holding jobs, and require the input of people who know the codebase well.
That's unrelated to licensing. Tech3 isn't exactly the easiest engine to use unless you are trying to make a Quake style game, whereas RO is built on the Unreal 2 engine which already has support for vehicles and a bunch of other stuff completely outside the scope of the Quake engine. The Unreal engine is seriously overengineered (in the good way) which makes it very moddable.
. They basically have to "give away" the game for free since once you've released full source code for your game, there is pretty much no reason to buy it.
In Tech3, the game code is written in C and targets a virtual machine. id released the game code and tools to use it with the released version, allowing a strong modding community to arise and just an opportunity for people to learn from the Q3 game logic.
ID later released the Tech3 engine and game code under the GPL. You could probably completely rewrite the game code license it under a non-GPL license (it only communicates with the engine via syscalls) and only have to distributed the engine source code, which is probably largely code written by others anyway. If you made any improvements you would have to release those too, but that's not really a problem and is contributing back to the community.
True, but I didn't realise Youtube was actually sharing that information publicly. When you signed up to a site years ago, who knows what information you entered and forgot about.
On a (related) side note, this seems interesting:
http://www.schneier.com/blog/archives/2009/04/identifying_peo.html
No, its real utility is seeing what is publicly accessible. I didn't realise my Youtube account was sharing my name (username), age and gender publicly.
Man up, learn LaTeX math syntax. I found I could generally take notes about as quickly as they were written using TeX. MediaWiki with the math mode extensions is good too, and more accessible than a linear document.
TeX becomes painful when you end up trying to take notes that involve tables with mixtures of summations and program code; when it gets tough, use a pen and paper, and transfer it to your computer readable notes later, otherwise you spend so long trying to format it that you don't concentrate on what the lecturer is saying!
Regular folk may find this hard to fathom, but software like Windows, Sharepoint and Office are the results of logical, mechanical execution of a process by a computer. The illogical nature is caused by the people writing the software: `weird' models for representing the problem (think, how Word represents formatting at a low level quite possibly differs from how you need to think about formatting a document), failure to consider all possible use cases (a program just cannot do something that seems obvious it should to you -- Excel doesn't seem to have a way to easily transform a lot of data -- workarounds exist), or very poorly designed user interfaces. A good, logical, usable program requires good, logical design on all levels.
I have none of those things. Cellular broadband is prohibitively expensive in this country (New Zealand). I would pay for this device, it sounds useful, I've even considered making some kind of device that would allow me to browse Wikipedia offline.
It's not a desirable position, and Microsoft hasn't been forthcoming about which patents it infringes. I don't think that rhetoric works however, it's quite likely that any functional software that would replace Linux will infringe on patents too; there are plenty of programming languages/libraries people can use that are a much safer bet for developing new applications than Mono.
For small projects/individuals, it is not likely the patents will cause a significant problem. If you are a company looking to build a product that uses Mono, then the Tom-Tom case should probably make you think twice, especially if your product competes with Microsoft in some way. Or, for popular software packages such as Gnome to rely on it too heavily.
I completely agree with you about software patents.
The FSF's purpose is to advocate the use of Free Software. While they will argue that you should use free software exclusively, and choose to do this themselves, they do not insist that users of free software, or GNU contributors do the same.
What you speak of is a different (non)issue. The FSF won't stop you from running proprietary software, you have the freedom to do so (unless your computer runs an operating system that doesn't respect that freedom).
One could argue that a free operating system that prevented you from running proprietary software would contradict freedom 0 (run and use the program for any purpose) and thus be non-free.
Are you confusing Mono with Wine? Mono is an implementation of the Common Language Runtime and.NET libraries. Very few games are written purely in.NET, and many will invoke native Windows API calls.
Stallman's warnings about Mono are not criticisms of the languages/runtimes themselves (the language and libraries are reasonably good), but that Microsoft holds patents over aspects of the implementation that Mono almost certainly infringes on and does not have a legally binding license to use. Given Microsoft's attitude towards free software and GNU/Linux, and the patent infringement case against Tom-Tom, it would be very unwise to rely on Mono.
I feel "the Free Software Foundation's view of freedom" captures that.
The Free Software Foundation focuses on the freedoms of all users, not just a subset of users. This is why they prefer copyleft style licences: the freedoms originally granted by the copyright holder are preserved for all subsequent users.
Devices that use free software, allow the software to be upgraded, but will only work with versions signed by some third party are seen as circumventing some of the four fundamental freedoms but permitted by the GPLv2. While you may still be free to look at the source code and modify it, chances are it is useless to you because you cannot run it on the actual device.
The argument that end users (non-programmers) can't benefit from these freedoms anyway is flawed, because you can still benefit from improvements made by others. While it's a slightly different situation, you (theoretically) don't have to be a programmer to use Rockbox, or OpenWRT, the hardware doesn't prevent you from doing this. In the case where the software on the device is originally free software, users can benefit from community improved distributions, etc.
Linus Torvalds has said he does not have a problem with Linux being used in this way (and has misled a lot of people with his incorrect explanations of the GPLv3). He does not necessarily see continued freedom of all users as important.
I fail to see how this is a personal attack. In some contexts, Linus doesn't believe in the Free Software Foundation's view of freedom, especially with respect to including proprietary firmware in the kernel, and the use of Linux in products that reduces user freedoms through technological measures (such as only executing signed software).
I used to have the idea that Java was inherently slow. It is not. Some implementations of the Java libraries are slow, Swing is a bit sluggish on some platforms (it is largely coded in Java rather than using native toolkit functionality) but the Java language itself is quite fast. If coded well, you can get performance comparable to C, but that is also quite dependent on how well your virtual machine JIT compiles the code (or, if it does).
I'm sure a lot of people base their preconceptions of Java being slow on programs like Azureus and Eclipse. These programs are slow because they are big and bloated, not just because they are coded in Java. On GNU/Linux systems especially (older Ubuntu releases were bad for this), the packages distributed in the repository would run use GCJ even when the much more efficient Sun runtime was installed.
The way I see it, Desktop GNU/Linux is becoming more and more like a 'microkernel'. Applications are not being programmed against the Linux interfaces and glibc and X, they are being programmed against Gtk/Glib or Qt; X is conceptually 'the operating system' as far as graphics applications are concerned, and the newer system daemons (PulseAudio, NetworkManager, D-bus, etc.) are becoming 'the operating system' for other aspects.
Likewise with sound, PulseAudio is a daemon to mitigate the shittiness and incompatibilities of the low level kernel interfaces (Alsa, OSS, whatever). I don't entirely like the implementation, and there were teething issues in distributions like Ubuntu (wasn't ready for primetime etc.) but it could effectively replace these low level kernel APIs from a regular application's point of view. ESD, Arts, Jack, whatever are all similar but with different priorities. Many of them run on a per-user basis though.
For hardware access, desktop applications use systems like HAL. What is HAL? It's doing the kernel's job. It provides better device APIs to applications, more portable ways to mount and configure stuff, portable access to power management etc.
NetworkManager. Manages network configuration. Provides a far more integrated way to control and configure network set up.
D-bus. Interprocess communication mechanism. Is used to tie all these services together, and provide a way for 'user applications' -- or libraries -- to communicate with these services.
From the kernel side of things, FUSE... getting used more and more to shift filesystems into userspace. NTFS, GVFS etc. Does it matter to users that it is running outside the kernel? No, because computers are fast enough that for a majority of purposes it is irrelevant. I currently run a custom Fuse filesystem for managing music (supports directory unions, designed to accommodate removable devices, allows me to store files in vorbis/flac hides vorbis ones if flac version exists). It is coded very naively, in fact it does a low level file open on every read call. I haven't improved that because the performance impact is negligible for its use.
Maybe someone should tell the kernel guys.
Most of these have implementation flaws, X can be a bit fragile, PulseAudio has been unstable at times and introduces latency, and so on. They aren't ideal, but they are a hell of a lot better than what Linux directly provides.
This is somewhat where BeOS/Haiku design excels, it has a lightweight hybrid/micro kernel with servers logically providing useful interfaces to applications. It's easy to write applications because there is an easy to use "media kit" (i.e. vaguely equivalent to PulseAudio in the desktop GNU/Linux architecture), there is a "MIDI kit" which provides a MIDI API, and so on. Nice, clean and integrated.
This is where desktop Linux needs to go. Saying 'oh if we got rid of X it would be fine' is easy, but it wouldn't be easy to do. X needs to get better and will, and we need to work with that. Integration and standardisation should be key and if that means restructuring how stuff has historically worked (X display managers, system init come to mind as examples) then it should be done that way, rather than chasing after impractical solutions. If the server model is better suited to making portable applications (which it certainly appears to be) then maybe Linux should move to a more microkernel-like model, and aim to provide better APIs to these user-space servers, rather than trying to duplicate work.
In the hands of an experienced programmer, a good language can be used to solve problems using an appropriate paradigm. It is relatively easy to code something equivalent to polymorphism/dynamic method dispatching in C, the compiler just doesn't do it for you.
That aside, C++ is more like a sword where the handle is replaced with another blade. If handled very carefully, one can become proficient in its use, but it is going to draw blood from time to time, regardless of your experience level.
I think intention comes into the question too. If you had an existing application and you linked against a GPL library for the sake of providing compatibility with some other software (i.e. a file exporter...), your application is hardly a derivative work of the library and you could probably get away with that; it's quite possible that the copyright holder might grant an exception. Of course, you should probably consult a lawyer with experience in this field, or perhaps the SFLC for advice.
To charitably reconstruct the OP's question, if you were doing it to use said library with specific intention of creating a non-GPL 'derivative work', even though it is indirect it would probably still be considered copyright infringement.
On top of this, it is irrelevant because glibc (the library practically every Linux C program links against [G for GNU]) is licensed under the lesser general public licence. This explicitly allows you to create derivative works (i.e. linking programs) as long as you respect certain conditions (allow users to modify the LGPL parts... this condition is a messy one in some cases).
The libraries for most proprietary Unix systems are under even more strict licenses. SCO's original grounds for suing Autozone were because while Autozone was migrating to GNU/Linux on some of their systems, they had copied the development libraries (and had programs linked against them) in unauthorized ways. Ultimately it seems this claim was invalid because Autozone still had a license for OpenServer, among other things.
And I do not think that Python is necessarily to blame here.
I cannot say for sure without profiling, but I think that for most interactive uses the perceived performance problems are not in tight Python logic loops, but in rendering and other basic stuff which mainly happens in C libs.
Precisely. The problem is the othe crap that runs on it. It has a large amount of a Gnome and Fedora system. On top of that, there are shitty problems with it that aren't getting solved any time soon, such as with Evince. Open a PDF, zoom in (and out if necessary, back out). Out of memory, segfault. It's a problem with Evince, allocating space for each zoom level and rendering it. The Gnome guys weren't interested in fixing it (most desktop systems have enough memory it isn't a huge problem), the OLPC people aren't patching it. It's stupid.
Slashdot Mirror
Whenever these articles come up people make the same error in the comments. Dynamic range compression IS NOT data compression. If you apply dynamic range compression (so that the difference between the loudest sounds and quietest sounds is reduced and then amplified --- higher RMS amplitude --- louder) the music has no subtleties to be lost by compression. Find an original or remastered recording of a band from yesteryear that play complex, well recorded music (a lot of jazz or jazz-influenced bands fall into this category, Steely Dan are one of my favourites, there are plenty of others) and compress the track with MP3. Compare. There is generally a very audible difference. I have a couple of MP3 rips in my music collection which occasionally get played instead of the FLAC version; I can hear it straight away, the percussion generally sounds flat and muted, or symbols are very harsh.
Partially need, partially choice. 8 bits represents a useful amount of information --- it's enough to represent basic text with control characters. It's a power of two, and an 8 bit binary number can be represented by two complete hexadecimal digits (i.e. 0x00 -- 0xFF), and is a factor of other common integer sizes --- 32 bits is 4*8 bits.
In Unix if malloc returns null then the memory allocation failed and you don't have the memory. A well written program should check that. Overcommitting memory can have efficiency advantages, but things can also turn out badly. Linux has heuristics to determine how much to overcommit the memory, or it can be disabled entirely.
http://utcc.utoronto.ca/~cks/space/blog/unix/MemoryOvercommit
http://utcc.utoronto.ca/~cks/space/blog/linux/LinuxVMOvercommit
But if the cost of the engine license is about $100,000 (for example), that might pay for one supporting programmer for a year and a half. The support roles however are not just hand-holding jobs, and require the input of people who know the codebase well.
That's unrelated to licensing. Tech3 isn't exactly the easiest engine to use unless you are trying to make a Quake style game, whereas RO is built on the Unreal 2 engine which already has support for vehicles and a bunch of other stuff completely outside the scope of the Quake engine. The Unreal engine is seriously overengineered (in the good way) which makes it very moddable.
. They basically have to "give away" the game for free since once you've released full source code for your game, there is pretty much no reason to buy it.
In Tech3, the game code is written in C and targets a virtual machine. id released the game code and tools to use it with the released version, allowing a strong modding community to arise and just an opportunity for people to learn from the Q3 game logic.
ID later released the Tech3 engine and game code under the GPL. You could probably completely rewrite the game code license it under a non-GPL license (it only communicates with the engine via syscalls) and only have to distributed the engine source code, which is probably largely code written by others anyway. If you made any improvements you would have to release those too, but that's not really a problem and is contributing back to the community.
True, but I didn't realise Youtube was actually sharing that information publicly. When you signed up to a site years ago, who knows what information you entered and forgot about.
On a (related) side note, this seems interesting:
http://www.schneier.com/blog/archives/2009/04/identifying_peo.html
http://www.google.com/support/accounts/bin/answer.py?answer=162743
No, its real utility is seeing what is publicly accessible. I didn't realise my Youtube account was sharing my name (username), age and gender publicly.
Man up, learn LaTeX math syntax. I found I could generally take notes about as quickly as they were written using TeX. MediaWiki with the math mode extensions is good too, and more accessible than a linear document. TeX becomes painful when you end up trying to take notes that involve tables with mixtures of summations and program code; when it gets tough, use a pen and paper, and transfer it to your computer readable notes later, otherwise you spend so long trying to format it that you don't concentrate on what the lecturer is saying!
Regular folk may find this hard to fathom, but software like Windows, Sharepoint and Office are the results of logical, mechanical execution of a process by a computer. The illogical nature is caused by the people writing the software: `weird' models for representing the problem (think, how Word represents formatting at a low level quite possibly differs from how you need to think about formatting a document), failure to consider all possible use cases (a program just cannot do something that seems obvious it should to you -- Excel doesn't seem to have a way to easily transform a lot of data -- workarounds exist), or very poorly designed user interfaces. A good, logical, usable program requires good, logical design on all levels.
I have none of those things. Cellular broadband is prohibitively expensive in this country (New Zealand). I would pay for this device, it sounds useful, I've even considered making some kind of device that would allow me to browse Wikipedia offline.
It's not a desirable position, and Microsoft hasn't been forthcoming about which patents it infringes. I don't think that rhetoric works however, it's quite likely that any functional software that would replace Linux will infringe on patents too; there are plenty of programming languages/libraries people can use that are a much safer bet for developing new applications than Mono.
For small projects/individuals, it is not likely the patents will cause a significant problem. If you are a company looking to build a product that uses Mono, then the Tom-Tom case should probably make you think twice, especially if your product competes with Microsoft in some way. Or, for popular software packages such as Gnome to rely on it too heavily.
I completely agree with you about software patents.
The FSF's purpose is to advocate the use of Free Software. While they will argue that you should use free software exclusively, and choose to do this themselves, they do not insist that users of free software, or GNU contributors do the same.
What you speak of is a different (non)issue. The FSF won't stop you from running proprietary software, you have the freedom to do so (unless your computer runs an operating system that doesn't respect that freedom).
One could argue that a free operating system that prevented you from running proprietary software would contradict freedom 0 (run and use the program for any purpose) and thus be non-free.
Are you confusing Mono with Wine? Mono is an implementation of the Common Language Runtime and .NET libraries. Very few games are written purely in .NET, and many will invoke native Windows API calls.
Stallman's warnings about Mono are not criticisms of the languages/runtimes themselves (the language and libraries are reasonably good), but that Microsoft holds patents over aspects of the implementation that Mono almost certainly infringes on and does not have a legally binding license to use. Given Microsoft's attitude towards free software and GNU/Linux, and the patent infringement case against Tom-Tom, it would be very unwise to rely on Mono.
I feel "the Free Software Foundation's view of freedom" captures that.
The Free Software Foundation focuses on the freedoms of all users, not just a subset of users. This is why they prefer copyleft style licences: the freedoms originally granted by the copyright holder are preserved for all subsequent users.
Devices that use free software, allow the software to be upgraded, but will only work with versions signed by some third party are seen as circumventing some of the four fundamental freedoms but permitted by the GPLv2. While you may still be free to look at the source code and modify it, chances are it is useless to you because you cannot run it on the actual device.
The argument that end users (non-programmers) can't benefit from these freedoms anyway is flawed, because you can still benefit from improvements made by others. While it's a slightly different situation, you (theoretically) don't have to be a programmer to use Rockbox, or OpenWRT, the hardware doesn't prevent you from doing this. In the case where the software on the device is originally free software, users can benefit from community improved distributions, etc.
Linus Torvalds has said he does not have a problem with Linux being used in this way (and has misled a lot of people with his incorrect explanations of the GPLv3). He does not necessarily see continued freedom of all users as important.
Blah
I fail to see how this is a personal attack. In some contexts, Linus doesn't believe in the Free Software Foundation's view of freedom, especially with respect to including proprietary firmware in the kernel, and the use of Linux in products that reduces user freedoms through technological measures (such as only executing signed software).
I used to have the idea that Java was inherently slow. It is not. Some implementations of the Java libraries are slow, Swing is a bit sluggish on some platforms (it is largely coded in Java rather than using native toolkit functionality) but the Java language itself is quite fast. If coded well, you can get performance comparable to C, but that is also quite dependent on how well your virtual machine JIT compiles the code (or, if it does).
I'm sure a lot of people base their preconceptions of Java being slow on programs like Azureus and Eclipse. These programs are slow because they are big and bloated, not just because they are coded in Java. On GNU/Linux systems especially (older Ubuntu releases were bad for this), the packages distributed in the repository would run use GCJ even when the much more efficient Sun runtime was installed.
I'm not a Java fanatic, nor an IBM troll. /p.
Hurd is plagued by unnecessary complexity. It has some good ideas in it but it is really designed for computers of yesteryear.
The way I see it, Desktop GNU/Linux is becoming more and more like a 'microkernel'. Applications are not being programmed against the Linux interfaces and glibc and X, they are being programmed against Gtk/Glib or Qt; X is conceptually 'the operating system' as far as graphics applications are concerned, and the newer system daemons (PulseAudio, NetworkManager, D-bus, etc.) are becoming 'the operating system' for other aspects.
Likewise with sound, PulseAudio is a daemon to mitigate the shittiness and incompatibilities of the low level kernel interfaces (Alsa, OSS, whatever). I don't entirely like the implementation, and there were teething issues in distributions like Ubuntu (wasn't ready for primetime etc.) but it could effectively replace these low level kernel APIs from a regular application's point of view. ESD, Arts, Jack, whatever are all similar but with different priorities. Many of them run on a per-user basis though.
For hardware access, desktop applications use systems like HAL. What is HAL? It's doing the kernel's job. It provides better device APIs to applications, more portable ways to mount and configure stuff, portable access to power management etc.
NetworkManager. Manages network configuration. Provides a far more integrated way to control and configure network set up.
D-bus. Interprocess communication mechanism. Is used to tie all these services together, and provide a way for 'user applications' -- or libraries -- to communicate with these services.
From the kernel side of things, FUSE... getting used more and more to shift filesystems into userspace. NTFS, GVFS etc. Does it matter to users that it is running outside the kernel? No, because computers are fast enough that for a majority of purposes it is irrelevant. I currently run a custom Fuse filesystem for managing music (supports directory unions, designed to accommodate removable devices, allows me to store files in vorbis/flac hides vorbis ones if flac version exists). It is coded very naively, in fact it does a low level file open on every read call. I haven't improved that because the performance impact is negligible for its use.
Maybe someone should tell the kernel guys.
Most of these have implementation flaws, X can be a bit fragile, PulseAudio has been unstable at times and introduces latency, and so on. They aren't ideal, but they are a hell of a lot better than what Linux directly provides.
This is somewhat where BeOS/Haiku design excels, it has a lightweight hybrid/micro kernel with servers logically providing useful interfaces to applications. It's easy to write applications because there is an easy to use "media kit" (i.e. vaguely equivalent to PulseAudio in the desktop GNU/Linux architecture), there is a "MIDI kit" which provides a MIDI API, and so on. Nice, clean and integrated.
This is where desktop Linux needs to go. Saying 'oh if we got rid of X it would be fine' is easy, but it wouldn't be easy to do. X needs to get better and will, and we need to work with that. Integration and standardisation should be key and if that means restructuring how stuff has historically worked (X display managers, system init come to mind as examples) then it should be done that way, rather than chasing after impractical solutions. If the server model is better suited to making portable applications (which it certainly appears to be) then maybe Linux should move to a more microkernel-like model, and aim to provide better APIs to these user-space servers, rather than trying to duplicate work.
I often find the opposite is true
That's a good thing. The distribution Asus used on the Eee PC was FUCKING TERRIBLE
In the hands of an experienced programmer, a good language can be used to solve problems using an appropriate paradigm. It is relatively easy to code something equivalent to polymorphism/dynamic method dispatching in C, the compiler just doesn't do it for you.
That aside, C++ is more like a sword where the handle is replaced with another blade. If handled very carefully, one can become proficient in its use, but it is going to draw blood from time to time, regardless of your experience level.
Like most people on Slashdot, I'm not a lawyer.
I think intention comes into the question too. If you had an existing application and you linked against a GPL library for the sake of providing compatibility with some other software (i.e. a file exporter...), your application is hardly a derivative work of the library and you could probably get away with that; it's quite possible that the copyright holder might grant an exception. Of course, you should probably consult a lawyer with experience in this field, or perhaps the SFLC for advice.
To charitably reconstruct the OP's question, if you were doing it to use said library with specific intention of creating a non-GPL 'derivative work', even though it is indirect it would probably still be considered copyright infringement.
On top of this, it is irrelevant because glibc (the library practically every Linux C program links against [G for GNU]) is licensed under the lesser general public licence. This explicitly allows you to create derivative works (i.e. linking programs) as long as you respect certain conditions (allow users to modify the LGPL parts... this condition is a messy one in some cases).
The libraries for most proprietary Unix systems are under even more strict licenses. SCO's original grounds for suing Autozone were because while Autozone was migrating to GNU/Linux on some of their systems, they had copied the development libraries (and had programs linked against them) in unauthorized ways. Ultimately it seems this claim was invalid because Autozone still had a license for OpenServer, among other things.
And I do not think that Python is necessarily to blame here. I cannot say for sure without profiling, but I think that for most interactive uses the perceived performance problems are not in tight Python logic loops, but in rendering and other basic stuff which mainly happens in C libs.
Precisely. The problem is the othe crap that runs on it. It has a large amount of a Gnome and Fedora system. On top of that, there are shitty problems with it that aren't getting solved any time soon, such as with Evince. Open a PDF, zoom in (and out if necessary, back out). Out of memory, segfault. It's a problem with Evince, allocating space for each zoom level and rendering it. The Gnome guys weren't interested in fixing it (most desktop systems have enough memory it isn't a huge problem), the OLPC people aren't patching it. It's stupid.