Lennart gripes in that post about some kernel patches that Ubuntu included -- but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes. (Running in a real-time class can improve latencies because that app gets to run ahead of most other apps and kernel tasks. A lot of the real-time development on Linux has been driven by audio people looking for more controlled latencies, but that was also before PA.)
In the days of yore, Linux applications didn't need to run at real-time priority to get reasonably good, low-latency audio performance. In days of yore, in fact, they got reasonably good, low-latency audio performance on relatively slow hardware before Linux had anything like true real-time priorities. Please explain to me how PA's apparent requirement to run in a real-time priority class on much faster systems is Ubuntu's fault.
A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.
Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.
Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.
After reading your post made "as a PA developer", I'm even more down on it than before.
The funny part is that if you have what the 99.9..% want, accessed through a reasonably thin shared library, it becomes pretty easy to forward it over a network. You end up with higher latency, but PA certainly seems to be putting the cart before the horse.
As a developer, I agree with you on everything except the paper airplanes. At work, I tell people to file different bug reports when they combine things, but that's part of what they get paid to do. For my open source work, I'm happy to get problem reports -- and in general, the more detailed, the better -- and if I think a bug report should be split, I'll split it as many ways as makes sense to me.
I come from the land of Linux, where malloc() and free() are the same functions no matter which DLL in a process's address space calls them -- and if the ABI for one happens to change for whatever reason, the C library takes care to provide backwards compatibility wrappers. As a result, most shared libraries use the C heap management routines.
Even by your mindset of "subsystems", malloc() and free() are part of the subsystem known as the standard C library, so memory allocation should work better than it does under Windows. Calling me names doesn't change that Microsoft continues to hose up their C runtime libraries.
I have also worked with standards that require some functions return pointers that are to be deallocated by calling free(). I am inclined to agree that a library would be unwise to promise that something can be deallocated with free(), but I wasn't the one making that decision.
(I won't even get started on C++: The frequent changes to ABI under Linux make life harder than it should have to be, but at least if your executable links -- statically or dynamically -- you're not likely to have new/delete resolution problems. Under Windows, DLLs have to provide replacements for delete or use COM objects instead of C++ objects.)
The real problem is C version Y not being backward compatible to C version X, leading to this idiocy of piling more and more complexity on top of a totally rotten mechanism.
It might surprise you, but Microsoft isn't actually to blame here. Rather, the legions of incompetent programmers that wrote DLLs such as C are to blame. We'd call them idiots, but Microsoft calls them paying customers. Thus prompting them to design SxS and incorporate it in WinXP.
Also, SxS is what made the restyling of the UI (through common controls version 6) technically possible.
Microsoft takes backwards compatibility very seriously.
They don't take it seriously. They don't even try for DLL compatibility within a product release. Can you really say with a straight face that you can new using MSVCR70.DLL and delete using MSVCR40.DLL, and get away with it? What about MSVCR80D.DLL and MSVCR80.DLL?
I'd bet dollars to donuts (adjusted for inflation) that the majority of problems caused by that incompatibility are due to Microsoft's C and C++ runtime libraries and their tendency to allocate memory from different arenas. My coworkers and I mostly program for Linux, but those few who have spent much time coding on Windows see that variant cause problems more often than practically anything else. How often you see third-party libraries cause DLL hell (that is, libraries not written by the application author) where those libraries are written by someone other than Microsoft?
This can bite you in a lot of conditions. One of the canonical examples is memory allocation. For example, foo.dll allocates memory and passes the pointer to bar.exe. To operate safely, bar.exe has to pass the pointer back to foo.dll so it can be freed. Otherwise, foo.dll might be using -- say -- malloc() and free() from one version of the C runtime library, and bar.exe might be using malloc() and free() from a different version. Because the different DLLs will end up allocating from different arenas, you'll corrupt both if you malloc() using one and free() using the other.
There's a reasonable argument that passing memory ownership without providing allocation functions is a bad way to design libraries. Unfortunately, some interface standards specify bindings that forbid providing that kind of deallocation function in the DLL. (I'm looking at you, CCSDS SLE! I still haven't forgiven you for inflicting this form of DLL hell upon me so many years ago.)
Those rules only apply where the hosting company actually serves copies of the allegedly infringing content -- that is, when someone has Ebay serving up copyrighted text, images, video or the like. It doesn't apply for advertisements or offers for sale.
Palm's agreements with USB-IF don't have squat to do with whether Apple is abusing monopoly power. One would be a civil case (or, more likely, mandatory arbitration) between Palm and the USB-IF licensing body. The other would be a criminal case -- United States v. Apple.
A loss leader is a product that is sold to consumers for less than it costs the seller, with the expectation that consumers will buy other products as part of the deal. Unless there are a lot of people who pay for iTunes rather than use the free download (or get it bundled with other Apple products), it is a loss leader, and advertising revenues from the iTunes Store -- or any other B2B revenues that Apple sees from iTunes -- don't change that.
Good luck with that -- as much as I like my PS3, the new ("slim") PS3 models come without support for Other OS installation. Sony's official statements on the subject indicate that it isn't coming back, either.
Palm was rather sleazy in trying to hijack Apple's software to do things that Apple doesn't want to support. On the other hand, I more than halfway expect Palm to now file an anti-trust complaint against Apple for abusive vertical integration on the basis that Apple has a practical monopoly in some of the areas here. It would be a somewhat weak claim -- there are other digital music stores, and other ways to synchronize music between devices, but Apple has a pretty commanding share of those markets plus the digital music player market. iTunes's nature as a loss leader seems like it could cut either for or against Apple.
It appears that the motivation of this AI is to send out promotional material for its professors. It's not a new type of observation, though, and a lot of people work through the logic of this situation in high school or early college. I'm not sure why a neuroscientist's talk on it would do more than rehash what is obvious to people with a reasonable amount of introspective ability.
There was a story in one of the Year's Best Science Fiction anthologies (2004 or so, I think) that discussed the motivation problem. A cutting-edge, type-A robotics developer builds progressively smarter and busier AIs, until suddenly the robots just sit there most of the time. His son sat around at home, surfing the web but not taking on hobbies or whatever. Both the robots and the kid realized that they could handle the (effectively mid-Singularity) world quite efficiently by monitoring information and reacting rather than trying to push things in a particular direction. In some ways, those types end up as free riders, but they can also be viewed as market makers (rather than movers).
Taxes are not just determined by location; many times, taxes are also determined by type of goods, calendar date, or other aspects. "Type of goods" will also vary from jurisdiction to jurisdiction: Large-tip markers might qualify for "back to school" tax holidays in one state, but not in the next state.
And if you think the onus to fix mistakes is ever going to be on government rather than on private parties, you're naive.
These things can be and are detected by proper testing.
That's an interesting definition of "proper testing". By any chance do you have infinite time and monkeys available for your testing?
Most complicated systems -- especially ones that involve embedded software -- are so complicated nowadays that you cannot plausibly test enough cases to determine whether the system has defects. You need good design approaches and multiple levels of (and approaches to) testing to reduce the number of defects to an acceptable number.
If you find a lot of bugs through traditional testing, and fix them all, that does not suggest that you will find fewer bugs in the future. It almost always indicates that you have even more bugs to find. (Beyond the fact that it means your defect density was too high in the first place, changing N lines of code -- for any reason -- is more likely to introduce new defects than writing N new lines of code.)
Bribery is an unwritten law in most of the countries where you see this kind of action. Where is your venom for them? Why should these countries not suffer embargoes or heightened tariffs because their governments permit -- and even require -- corrupt business practices?
If and when international law comes down hard on officials who solicit bribes, I will agree that it should come down hard on the other side of that corrupt coin. Unfortunately, the people who will have to agree to that law are the people who accept the bribes. If you can solve that problem, you'll probably solve most of the other problems in government at the same time.
The calculation for total energy would depend on the X axis. I think derGoldstein's point was that higher frequency photons have higher energy per unit of luminous flux, so that green light might have higher flux but not the most energy over a fixed width swath of frequencies.
The issue is not so much melting sea ice as melting glaciers. Antarctica and Arctic land masses are the areas of concern; if their glaciers flow into the sea -- even if they do not melt -- ocean levels will significantly.
Can you #include header files from GPLed code in proprietary code?
Of course you can. The question is: What happens next? If you want to distribute the proprietary code (in either source or binary format), you have to evaluate whether the use of the header file -- and in particular the contents of the header file -- makes the proprietary code subject to the GPL. If you want to rely on the answer in court, you had better have a qualified lawyer make that evaluation, and such a lawyer is likely to tell you that it's simpler and easier to just assume the GPL covers your wanted-to-be-proprietary code.
The problem is that too many people think that easy modifications mean it is a good idea to try something and see what breaks. Sure, that works for sufficiently trivial applications. It doesn't work so well for most applications that grow beyond a thousand lines of language statements. Writing truly robust software requires the use of abstract reasoning about the requirements and constraints for each piece of software.
There is usually a combination of settings for core.autocrlf and/or core.safecrlf that will do what you want, although finding it (and making sure it works the way you want) can be time-intensive and sometimes tricky. I had the same headaches when I converted from a Subversion repository (with wrong-format EOL characters, due to developing under Windows but committing under Linux) to git, and eventually settled for core.autocrlf=false. The.gitattributes file allows you to override the global and repository-wide options on a per-file (or per-glob) basis.
For a regular update, why not use "git fetch origin && git rebase master" (if the "master" branch is set up to follow a branch from a remote "origin" repository)? I'm not sure what "check for errors or dirty files" means -- it is not a step that I ever have to perform when pushing or pulling master branches in git, but otherwise your regular update path collapses to just a fetch and rebase.
For commits, I would recommend using git gui. I am usually a command line guy, but git gui makes it much easier for me to review changes, stage them, compose the commit message, commit and push.
git has good support for projects that are built from smaller chunks -- these are called submodules. Splitting an existing project into smaller chunks after the fact is where git becomes a bit annoying.
You are right that the user interface is often the biggest problem when a person is programming computers. (I am not sure that Dijkstra was thinking about that, because when he wrote that the user interface was typically a simple command-line affair.) The most common fault in user interfaces is that programs meant for non-programmer users tend to expose a computer's inherent non-linearity too easily or too much.
Whining that the user perspective is "rather silly from a computer science point of view" is irrelevant; the computer science point of view is not the only relevant one. Unless you think everyone in the world should be trained as a competent computer programmer, understanding computers at the level Dijkstra advocates is not a solution to informal or incomplete program specifications.
Again, his beef is that programmers do not -- at least, not often enough -- view writing a program as an exercise in constructing a thing that provably meets a formal specification. In the end, the person who is paying for the work will almost always decide "Oh, did I say *that*? What I really want is __(some other thing)__." Vendors tend to do the same thing. These changes require a rework of some, and perhaps much, of the formal specification and of all the downstream work. Until and unless everyone becomes a perfect systems analyst, you will not remove that disconnect.
Not to unduly demean wankery, but figuring out ways to cope with that is what separates software engineering practice from computer science wankery.
Slashdot Mirror
Lennart gripes in that post about some kernel patches that Ubuntu included -- but his fundamental complaint is that Ubuntu didn't add a different patch, to allow an application called rtkit to put other processes in real-time priority classes. (Running in a real-time class can improve latencies because that app gets to run ahead of most other apps and kernel tasks. A lot of the real-time development on Linux has been driven by audio people looking for more controlled latencies, but that was also before PA.)
In the days of yore, Linux applications didn't need to run at real-time priority to get reasonably good, low-latency audio performance. In days of yore, in fact, they got reasonably good, low-latency audio performance on relatively slow hardware before Linux had anything like true real-time priorities. Please explain to me how PA's apparent requirement to run in a real-time priority class on much faster systems is Ubuntu's fault.
A lot of devices stream data over a network and play it locally as audio. That does not necessarily make any of them a "network based" audio device in the sense that they can be driven by PA.
Audio is not unique in needing device ACLs adjusted; it should not need a unique solution for doing that. In fact, having an audio server handle ACL adjustments when something else does that is a violation of the Unix philosophy of chaining together simple tools that focus on one thing.
Application-controlled latency is good. Library-enforced latency is bad. Sending audio from one user-space process to another is a case of the latter.
After reading your post made "as a PA developer", I'm even more down on it than before.
The funny part is that if you have what the 99.9..% want, accessed through a reasonably thin shared library, it becomes pretty easy to forward it over a network. You end up with higher latency, but PA certainly seems to be putting the cart before the horse.
As a developer, I agree with you on everything except the paper airplanes. At work, I tell people to file different bug reports when they combine things, but that's part of what they get paid to do. For my open source work, I'm happy to get problem reports -- and in general, the more detailed, the better -- and if I think a bug report should be split, I'll split it as many ways as makes sense to me.
(Or, more briefly, mod parent up!)
If you name it Hyperdrive now, what will you name a FTL drive? Full-speed Hyperdrive? Hi-Speed?
Obviously, hyper-er-drive!
I come from the land of Linux, where malloc() and free() are the same functions no matter which DLL in a process's address space calls them -- and if the ABI for one happens to change for whatever reason, the C library takes care to provide backwards compatibility wrappers. As a result, most shared libraries use the C heap management routines.
Even by your mindset of "subsystems", malloc() and free() are part of the subsystem known as the standard C library, so memory allocation should work better than it does under Windows. Calling me names doesn't change that Microsoft continues to hose up their C runtime libraries.
I have also worked with standards that require some functions return pointers that are to be deallocated by calling free(). I am inclined to agree that a library would be unwise to promise that something can be deallocated with free(), but I wasn't the one making that decision.
(I won't even get started on C++: The frequent changes to ABI under Linux make life harder than it should have to be, but at least if your executable links -- statically or dynamically -- you're not likely to have new/delete resolution problems. Under Windows, DLLs have to provide replacements for delete or use COM objects instead of C++ objects.)
It might surprise you, but Microsoft isn't actually to blame here. Rather, the legions of incompetent programmers that wrote DLLs such as C are to blame. We'd call them idiots, but Microsoft calls them paying customers. Thus prompting them to design SxS and incorporate it in WinXP.
Also, SxS is what made the restyling of the UI (through common controls version 6) technically possible.
Microsoft takes backwards compatibility very seriously.
They don't take it seriously. They don't even try for DLL compatibility within a product release. Can you really say with a straight face that you can new using MSVCR70.DLL and delete using MSVCR40.DLL, and get away with it? What about MSVCR80D.DLL and MSVCR80.DLL?
I'd bet dollars to donuts (adjusted for inflation) that the majority of problems caused by that incompatibility are due to Microsoft's C and C++ runtime libraries and their tendency to allocate memory from different arenas. My coworkers and I mostly program for Linux, but those few who have spent much time coding on Windows see that variant cause problems more often than practically anything else. How often you see third-party libraries cause DLL hell (that is, libraries not written by the application author) where those libraries are written by someone other than Microsoft?
This can bite you in a lot of conditions. One of the canonical examples is memory allocation. For example, foo.dll allocates memory and passes the pointer to bar.exe. To operate safely, bar.exe has to pass the pointer back to foo.dll so it can be freed. Otherwise, foo.dll might be using -- say -- malloc() and free() from one version of the C runtime library, and bar.exe might be using malloc() and free() from a different version. Because the different DLLs will end up allocating from different arenas, you'll corrupt both if you malloc() using one and free() using the other.
There's a reasonable argument that passing memory ownership without providing allocation functions is a bad way to design libraries. Unfortunately, some interface standards specify bindings that forbid providing that kind of deallocation function in the DLL. (I'm looking at you, CCSDS SLE! I still haven't forgiven you for inflicting this form of DLL hell upon me so many years ago.)
Those rules only apply where the hosting company actually serves copies of the allegedly infringing content -- that is, when someone has Ebay serving up copyrighted text, images, video or the like. It doesn't apply for advertisements or offers for sale.
Palm's agreements with USB-IF don't have squat to do with whether Apple is abusing monopoly power. One would be a civil case (or, more likely, mandatory arbitration) between Palm and the USB-IF licensing body. The other would be a criminal case -- United States v. Apple.
A loss leader is a product that is sold to consumers for less than it costs the seller, with the expectation that consumers will buy other products as part of the deal. Unless there are a lot of people who pay for iTunes rather than use the free download (or get it bundled with other Apple products), it is a loss leader, and advertising revenues from the iTunes Store -- or any other B2B revenues that Apple sees from iTunes -- don't change that.
Good luck with that -- as much as I like my PS3, the new ("slim") PS3 models come without support for Other OS installation. Sony's official statements on the subject indicate that it isn't coming back, either.
Palm was rather sleazy in trying to hijack Apple's software to do things that Apple doesn't want to support. On the other hand, I more than halfway expect Palm to now file an anti-trust complaint against Apple for abusive vertical integration on the basis that Apple has a practical monopoly in some of the areas here. It would be a somewhat weak claim -- there are other digital music stores, and other ways to synchronize music between devices, but Apple has a pretty commanding share of those markets plus the digital music player market. iTunes's nature as a loss leader seems like it could cut either for or against Apple.
It appears that the motivation of this AI is to send out promotional material for its professors. It's not a new type of observation, though, and a lot of people work through the logic of this situation in high school or early college. I'm not sure why a neuroscientist's talk on it would do more than rehash what is obvious to people with a reasonable amount of introspective ability.
There was a story in one of the Year's Best Science Fiction anthologies (2004 or so, I think) that discussed the motivation problem. A cutting-edge, type-A robotics developer builds progressively smarter and busier AIs, until suddenly the robots just sit there most of the time. His son sat around at home, surfing the web but not taking on hobbies or whatever. Both the robots and the kid realized that they could handle the (effectively mid-Singularity) world quite efficiently by monitoring information and reacting rather than trying to push things in a particular direction. In some ways, those types end up as free riders, but they can also be viewed as market makers (rather than movers).
Taxes are not just determined by location; many times, taxes are also determined by type of goods, calendar date, or other aspects. "Type of goods" will also vary from jurisdiction to jurisdiction: Large-tip markers might qualify for "back to school" tax holidays in one state, but not in the next state.
And if you think the onus to fix mistakes is ever going to be on government rather than on private parties, you're naive.
These things can be and are detected by proper testing.
That's an interesting definition of "proper testing". By any chance do you have infinite time and monkeys available for your testing?
Most complicated systems -- especially ones that involve embedded software -- are so complicated nowadays that you cannot plausibly test enough cases to determine whether the system has defects. You need good design approaches and multiple levels of (and approaches to) testing to reduce the number of defects to an acceptable number.
If you find a lot of bugs through traditional testing, and fix them all, that does not suggest that you will find fewer bugs in the future. It almost always indicates that you have even more bugs to find. (Beyond the fact that it means your defect density was too high in the first place, changing N lines of code -- for any reason -- is more likely to introduce new defects than writing N new lines of code.)
Bribery is an unwritten law in most of the countries where you see this kind of action. Where is your venom for them? Why should these countries not suffer embargoes or heightened tariffs because their governments permit -- and even require -- corrupt business practices?
If and when international law comes down hard on officials who solicit bribes, I will agree that it should come down hard on the other side of that corrupt coin. Unfortunately, the people who will have to agree to that law are the people who accept the bribes. If you can solve that problem, you'll probably solve most of the other problems in government at the same time.
The calculation for total energy would depend on the X axis. I think derGoldstein's point was that higher frequency photons have higher energy per unit of luminous flux, so that green light might have higher flux but not the most energy over a fixed width swath of frequencies.
The issue is not so much melting sea ice as melting glaciers. Antarctica and Arctic land masses are the areas of concern; if their glaciers flow into the sea -- even if they do not melt -- ocean levels will significantly.
Can you #include header files from GPLed code in proprietary code?
Of course you can. The question is: What happens next? If you want to distribute the proprietary code (in either source or binary format), you have to evaluate whether the use of the header file -- and in particular the contents of the header file -- makes the proprietary code subject to the GPL. If you want to rely on the answer in court, you had better have a qualified lawyer make that evaluation, and such a lawyer is likely to tell you that it's simpler and easier to just assume the GPL covers your wanted-to-be-proprietary code.
The problem is that too many people think that easy modifications mean it is a good idea to try something and see what breaks. Sure, that works for sufficiently trivial applications. It doesn't work so well for most applications that grow beyond a thousand lines of language statements. Writing truly robust software requires the use of abstract reasoning about the requirements and constraints for each piece of software.
There is usually a combination of settings for core.autocrlf and/or core.safecrlf that will do what you want, although finding it (and making sure it works the way you want) can be time-intensive and sometimes tricky. I had the same headaches when I converted from a Subversion repository (with wrong-format EOL characters, due to developing under Windows but committing under Linux) to git, and eventually settled for core.autocrlf=false. The .gitattributes file allows you to override the global and repository-wide options on a per-file (or per-glob) basis.
For a regular update, why not use "git fetch origin && git rebase master" (if the "master" branch is set up to follow a branch from a remote "origin" repository)? I'm not sure what "check for errors or dirty files" means -- it is not a step that I ever have to perform when pushing or pulling master branches in git, but otherwise your regular update path collapses to just a fetch and rebase.
For commits, I would recommend using git gui. I am usually a command line guy, but git gui makes it much easier for me to review changes, stage them, compose the commit message, commit and push.
git has good support for projects that are built from smaller chunks -- these are called submodules. Splitting an existing project into smaller chunks after the fact is where git becomes a bit annoying.
You are right that the user interface is often the biggest problem when a person is programming computers. (I am not sure that Dijkstra was thinking about that, because when he wrote that the user interface was typically a simple command-line affair.) The most common fault in user interfaces is that programs meant for non-programmer users tend to expose a computer's inherent non-linearity too easily or too much.
Whining that the user perspective is "rather silly from a computer science point of view" is irrelevant; the computer science point of view is not the only relevant one. Unless you think everyone in the world should be trained as a competent computer programmer, understanding computers at the level Dijkstra advocates is not a solution to informal or incomplete program specifications.
Again, his beef is that programmers do not -- at least, not often enough -- view writing a program as an exercise in constructing a thing that provably meets a formal specification. In the end, the person who is paying for the work will almost always decide "Oh, did I say *that*? What I really want is __(some other thing)__." Vendors tend to do the same thing. These changes require a rework of some, and perhaps much, of the formal specification and of all the downstream work. Until and unless everyone becomes a perfect systems analyst, you will not remove that disconnect.
Not to unduly demean wankery, but figuring out ways to cope with that is what separates software engineering practice from computer science wankery.