They're certainly nowhere near as Linux-friendly as Nvidia.
NV is Linux-friendly? Does that mean MS is merely 'Linux-neutral'?:)
No offense, but I think your definition of what a friend is... needs a little work.
As for AMD-ATI, give them another year or so, and check their open driver again. I'm sure that you'll be pleasantly surprised then (I'm using that in-development open driver now).
Hey moderator!... every single of my statements is a fact
This one isn't:
The Linux “team” of ATi is a one-man-show, and focuses only on workstations. Everything else is simply ignored.
You missed the part where AMD has devs working on the open driver as well.
As for the rest of your rant, everyone knows the fglrx driver sucks on Linux. What has changed is that ATI is now a subdivision of AMD, and the future of ATI graphics on Linux will be the open driver that is being (rapidly) developed as we speak, and in the end it'll be much better than anything NV is willing to provide.
Anyone brave enough to use that in-development version of AMD's open driver already knows what the future is going to look like. Give AMD another year or two to stabilize the open driver and bring it up to speed on chip support, performance tweaking, and handling corner-cases, and once that work makes it into the mainstream Linux releases, they will end up changing the world of Linux graphics support (as we've known it) forever.
After all, their driver will be entirely found within either the kernel (KMS) or Xorg itself (DRM/Mesa), so you'll no longer need a separate binary blob/package just to get hardware-accelerated 2D & 3D (anyone with AMD-ATI hardware will thus get all this goodness right out of the box, as soon as they install Linux). And thats just for starters...
Actually AMD/ATI has changed their attitude in last two years
ATI 'changed their attitude' the day after AMD bought them.:)
AMD has always been a more open/FOSS friendly company than either NV or ATI.
The buyout happened more than 2 years ago, its just taken some time for AMD to sort through everything and get up to speed with their support of non-Windows on the graphics side of things, since after all, they basically had to start from scratch (ATI was just as uninterested in non-Windows arches as NV still is).
FYI: Some of those people are actually AMD employees.
Your earlier rant about NV & ATI was correct, but ATI no longer exists, they're a sub-division of AMD now, and AMD at least seems to care about openness and supporting non-Windows OSes more than NV or ATI ever did. Not saying AMD is perfect, just a hell of an upgrade from what we had before.
Linus isn't a diplomat, he's a kernel hacker, and he's not the only kernel hacker who is not especially diplomatic. That's because being a diplomat is not his job.
a childish, whinging prat
If that was really what he is, then no one would pay attention to his rants. Instead, just days later, his rant accomplished real change, and for the better. NV hardware users (who want/like Nouveau) should be glad Linus is someone people listen too, no matter how undiplomatic he may be.
Besides, having read through that entire LKML thread (as of yesterday), I don't actually see Linus behaving particularly badly there (for him). He's said some especially stupid things in the past, but here, not so much, and I think he actually had a fair point about the upstreaming issue (which is probably why this change happened so quickly).
Me? I'd much rather have that 'whinging prat' in charge of the Linux kernel than a real diplomat.
1. Since we're pushing pixels instead of cells, things slow down an order of magnitude or two
Except the framebuffer driver you're now using is hardware-accelerated, which more than makes up for switching from chars to pixels. This was why so much effort went into all those chip specific fb drivers that are available. They're all much faster & more convenient than plain & dumb vgacon.
Sounds like you've never seen one of those hardware-accelerated console modes, or you'd realize just how slow/inefficient plain vgacon actually is. Its a night vs. day kind of difference.
2. Once the console drivers have bound onto fbcon and off of vgacon, there's no way to get vgacon back without rebooting.
That's true, but again that brings us back to my original question: why would you want to keep vgacon around when you have a hardware-accelerated, hi-res, hi-refresh fb driver replacement already there?
This, a unified, lowlevel graphics driver that is used by both fbcon & xorg, which gives the same advantages to both the Xorg and console modes, and now allows more cooperation between the two, is what many people have been wanting for a *long* time.
kiss text mode goodbye becasue the powers that be refuse to support it.
The ATI/Radeon driver, at least, provides its own hi-res console mode (all in the kernel, not dependent on Xorg, works with fbcon to act as a framebuffer driver), so why would you want the old VGA (low-res, low-refresh) mode anyway?
For special/embedded systems, they can always leave out that specific driver (ATI/NV/Intel) that does KMS, and keep the old VGA console code, its still in the kernel & available as an option.
You haven't lost anything, you just can't use both at the same time now, e.g. you can't (AFAICT) have the old VGA and the new KMS support builtin to the kernel at the same time.
Sure - but you're removing that from the context of a person wanting an incredibly light and simplistic system.
I think the GP was referring to a light/fast DE, whether the apps he uses on that DE are light or heavy is really his business.:)
If the DE itself is heavy though, that gets in the way of using heavy apps.
There are many ways to build a GUI, and not many are fatter than Eclipse.
Agreed, its heaviness, and the fact that it didn't provide a GUI designer as I described earlier whereas Netbeans does (though maybe thats changed since I looked at it), is why I've avoided it myself.
However, that 'heaviness' to you & I, means 'useful features' to others (Eclipse's strength seems to be in its plugin system), so I tend to avoid this kind of argument, since I sometimes find myself on the other side of the fence. For example, I favor Qt over Gtk even though the former is much 'heavier' than the latter.
There's your problem. That thing is notorious for poor 2D performance.
Like the GP, I'm running the latest FOSS ATI driver and speed is not an issue for me either (using KDE 4.3.3).
but 3.5.x ran quite well and was snappy regardless of which graphics chipset
That wasn't my experience, back when I was using an NV card and the driver you are using now.
Of course, it also depends on how you had KDE setup.
There has been a lot of finger pointing about graphics drivers in the 4.x series
KDE4 optionally pushes the graphics envelope further than 3.5 did, and thus tickled some problems (compositing) with the graphics drivers initially. AFAIK, this has been resolved for most users (at least with AMD/ATI), but I don't run with all the eye-candy turned on anyway, so this never affected me.
There are a few KDE devs who seem to the take the "admit no mistakes, push forward!" attitude
The only mistake they made was calling the 4.0 release a '4.0' release, IMO. As far as the UI changes in 4 (Plasma specifically), they were right to do so, even though it meant taking a step backwards temporarily. That was to some degree going to happen anyway as the internal differences between Qt3 and Qt4 were dramatic, so KDE4 was inevitably going to be a much more significant change from KDE3 than KDE3 was from KDE2.
And this all depends on the way people use the DE anyway. For some people KDE 4.3 is still 'worse' than 3.5, yet for others its already 'caught up'. The only missing component for me is the still incomplete conversion of Ksysguard from 3.5 - I still can't use that in KDE4 the way I could in 3.5, but for me at least, thats really just a nitpick.
The payoff is that now KDE4 is even more flexible and configurable than it was before, in terms of how you interact with it. For all of its new 'weird' features, you can *still* set it up to look and act just like 3.5 (which is what I've basically done).
This seems to be the only fundamental difference between KDE and Gnome: Gnome has largely one way of doing things, while KDE is basically a chameleon, its so configurable you can make it look or act like nearly anything else. The argument above us about one-click/double-click for example is utterly irrelevant in KDE, since you can configure it to use either method (and have every KDE-aware app behave in a consistent manner).
Seriously - why use Eclipse instead of gedit/kate/gvim/take your pick
I don't use Eclipse myself, but the usual reason for IDEs is that they can integrate the GUI development of your app with a WYSIWYG interface. Netbeans can do this for Swing (Java), QtCreator can do this for Qt, Kdevelop can do this for KDE (uses QtDesigner), etc. For development of GUI apps, an IDE like these makes sense.
The KDE2.x->KDE3.x wasn't a major change in the interface.
Because it wasn't a major change in the underlying toolkit. Qt3 wasn't fundamentally different from Qt2, only better, whereas the KDE3-to-4 switch was a switch from Qt3 to Qt4, and that was a *massive* change internally. Since they were going to have to rip apart the guts of KDE anyway for this change (necessary to take advantage of the new features of Qt4), they also decided to make some UI changes as well.
Only a moron would talk about how different C# and.NET are from Java.
I agree with the rest of what you say (C# is MS's Java killer), but the C# and Java core languages *are* different from one another, e.g. pointers and unsigned ints for just 2 examples, and to be completely fair, some of the C# differences are (minor) improvements over Java (MS had the advantage of hindsight here).
Anyway, enough differences even in the core languages themselves (never mind the completely *different* supporting libraries that both have) to make the porting of a non-trivial app from one to the other, well, *laughably* non-trivial.
But most importantly: No need for Red Hat? It's either don't use Windows and pay a competitor, or not pay a competitor. It's that simple.
For MS's shareholders it is just about the money, but for everyone else, its not that simple.
All I can say is that MS releasing a 'free' *nix clone of their own will not in any way entice me away from a real FOSS OS, because, of course, free or not, this is still MS we're talking about.
Unless you're idea is that they're going to release this clone under a *real* FOSS license, which ain't going to happen. MS releasing a GPL'd *nix clone? Not in this universe.
it has been shipping the Fast ESP platform on Linux and some other Unix platforms.
Its an enterprise level web-based portal software for businesses, being cross-platform is pretty much a requirement for that category.
When Linus said 'applications' I'm pretty sure he was thinking more along the lines of, say, MS Office, or basically anything the MS has that is Windows-only right now (FAST was already cross-platform before MS bought it).
Well you're right about the Linux kernel, but then again Gnome now *is* dependent on Mono, and a few years ago I wouldn't have thought that would happen, so...
you just port the application to Java, C++ or Go!.
Wait, I've been listening for years to fanbois tell me about how much better, and different, C# is compared to Java, and now you're telling me its a breeze to port any non-trivial C#/.NET app to Java/JVM?
Since Mono is a clean-room implementation of.NET and C# (both EMCA standards)
You don't *need* a clean-room implementation of an EMCA standard. Its a *standard*.
Its the 'clean-room implementations' of the non-ECMA-standard software at the top of the Mono software stack that have people concerned, e.g. Winforms & ASP.NET, etc, etc.
And the Community Promise
has so much vague language in it that its only real value is as comic relief.
Seriously, google what the FSF and others think about the language of that 'promise'.
Patents were made to spawn innovation - bypassing secretive guilds by incentivizing the opening of knowledge to public domain in exchange for a limited time monopoly. Projects and society are way too fluid now to keep many inane details secret anyway.
The patent concept was also invented with the idea of the physical widget in mind, at a time when making things was an expensive proposition. A real physical 'thing' that had to be *manufactured*. The goal: make companies more likely to make the massive investments in R&D, time, effort, material and capital acquisitions, tooling, retooling, e.g. making the tool that made the tool that finally made the widget itself, and then the final manufacturing process, renting the floor space, hiring the workers, setting up the 'assembly line'. For many 'real widgets' this is all expensive as hell. A limited monopoly was seen as a way to offset those expenses. As far as that all goes, it kinda makes sense, although we could always quibble about the length of the granted monopoly, or other relatively minor things, but...
Where is the equivalent massive expenditures involved in creating software? Software is not physical, its electronic, ephemeral (and never mind also being closer to an expression of mathematical algorithms than to something you see and hear and feel and touch like a physical thing). Most of the 'manufacturing process' goes on in the coders' heads, not on a shop floor.
And the 'worst-case' scenario (or best-case depending on your pov): Capitol investment? One cheap beige-box computer. Raw materials? Caffeine & cold pizza. Infrastructure? Mom's basement.
As soon as you look at the history of the patent and *why* it was created, the more today's picture seems out of focus. Its goal was never to simply reward the one who 'got there first', its original purpose was to help offset the real costs of inventing, so it would be financially worthwhile for someone to even try to do it at all. This is why it was simply a bad idea to apply it to a non-physical widget, because the real and practical reasons for doing this with physical widgets, do not really apply to software.
And don't even get me started on 'business method' patents... grrr...
The examiner has to make a prima facie case of unpatentability in order to reject a claim.
So the burden of proof on the overworked, underpaid (and possibly incompetent) examiner is thus set very high, possibly too high.
If the examiner can't substantiate such a case, the application gets allowed, and the applicant gets a patent.
Who is now free to use that patent against others like a bludgeon, and the burden of proof for the *defendant* ends up high as well, and even when they can do what the examiner could not (find prior art), they've already *lost* anyway, at least from a business's bottom-line-oriented (expense) point-of-view.
Only when the examiner makes a prima facie case does the burden shift to the applicant to either...
What burden? They just keep rewording and resubmitting it until they simply wear down the examiner...
Are (most) patent attorneys paid per application *attempted*, or per application *approved*, or strictly per hour?
What about companies with in-house staff? They've got nothing better to do than to keep chipping away at the USPTO, since every patent in their arsenal becomes worth the trouble in the case of a nuclear patent showdown with a rival...
I know Slashdot loves to exaggerate things in headlines, but this is absurd.
No sir, this is not absurd... this *is* Slashdot!
I'd guess the editors consider any TFA that generates 600+ posts to be a "good day's work", irrespective of the presence or absence of exaggeration and/or absurdity, *especially* if they don't have to invent the absurdity themselves, but merely link to it...
Slashdot Mirror
They're certainly nowhere near as Linux-friendly as Nvidia.
NV is Linux-friendly? Does that mean MS is merely 'Linux-neutral'? :)
No offense, but I think your definition of what a friend is... needs a little work.
As for AMD-ATI, give them another year or so, and check their open driver again. I'm sure that you'll be pleasantly surprised then (I'm using that in-development open driver now).
Hey moderator! ... every single of my statements is a fact
This one isn't:
The Linux “team” of ATi is a one-man-show, and focuses only on workstations. Everything else is simply ignored.
You missed the part where AMD has devs working on the open driver as well.
As for the rest of your rant, everyone knows the fglrx driver sucks on Linux. What has changed is that ATI is now a subdivision of AMD, and the future of ATI graphics on Linux will be the open driver that is being (rapidly) developed as we speak, and in the end it'll be much better than anything NV is willing to provide.
Anyone brave enough to use that in-development version of AMD's open driver already knows what the future is going to look like. Give AMD another year or two to stabilize the open driver and bring it up to speed on chip support, performance tweaking, and handling corner-cases, and once that work makes it into the mainstream Linux releases, they will end up changing the world of Linux graphics support (as we've known it) forever.
After all, their driver will be entirely found within either the kernel (KMS) or Xorg itself (DRM/Mesa), so you'll no longer need a separate binary blob/package just to get hardware-accelerated 2D & 3D (anyone with AMD-ATI hardware will thus get all this goodness right out of the box, as soon as they install Linux). And thats just for starters...
Actually AMD/ATI has changed their attitude in last two years
ATI 'changed their attitude' the day after AMD bought them. :)
AMD has always been a more open/FOSS friendly company than either NV or ATI.
The buyout happened more than 2 years ago, its just taken some time for AMD to sort through everything and get up to speed with their support of non-Windows on the graphics side of things, since after all, they basically had to start from scratch (ATI was just as uninterested in non-Windows arches as NV still is).
I use NVidia's closed drivers for Linux on my 8800GT and I have never, ever experienced a crash or lockup.
Some people are just damn lucky...
Otherwise your point is?
Some people are working on a Libre ATI driver.
FYI: Some of those people are actually AMD employees.
Your earlier rant about NV & ATI was correct, but ATI no longer exists, they're a sub-division of AMD now, and AMD at least seems to care about openness and supporting non-Windows OSes more than NV or ATI ever did. Not saying AMD is perfect, just a hell of an upgrade from what we had before.
Reading Linus' remarks
Linus isn't a diplomat, he's a kernel hacker, and he's not the only kernel hacker who is not especially diplomatic. That's because being a diplomat is not his job.
a childish, whinging prat
If that was really what he is, then no one would pay attention to his rants. Instead, just days later, his rant accomplished real change, and for the better. NV hardware users (who want/like Nouveau) should be glad Linus is someone people listen too, no matter how undiplomatic he may be.
Besides, having read through that entire LKML thread (as of yesterday), I don't actually see Linus behaving particularly badly there (for him). He's said some especially stupid things in the past, but here, not so much, and I think he actually had a fair point about the upstreaming issue (which is probably why this change happened so quickly).
Me? I'd much rather have that 'whinging prat' in charge of the Linux kernel than a real diplomat.
1. Since we're pushing pixels instead of cells, things slow down an order of magnitude or two
Except the framebuffer driver you're now using is hardware-accelerated, which more than makes up for switching from chars to pixels. This was why so much effort went into all those chip specific fb drivers that are available. They're all much faster & more convenient than plain & dumb vgacon.
Sounds like you've never seen one of those hardware-accelerated console modes, or you'd realize just how slow/inefficient plain vgacon actually is. Its a night vs. day kind of difference.
2. Once the console drivers have bound onto fbcon and off of vgacon, there's no way to get vgacon back without rebooting.
That's true, but again that brings us back to my original question: why would you want to keep vgacon around when you have a hardware-accelerated, hi-res, hi-refresh fb driver replacement already there?
This, a unified, lowlevel graphics driver that is used by both fbcon & xorg, which gives the same advantages to both the Xorg and console modes, and now allows more cooperation between the two, is what many people have been wanting for a *long* time.
kiss text mode goodbye becasue the powers that be refuse to support it.
The ATI/Radeon driver, at least, provides its own hi-res console mode (all in the kernel, not dependent on Xorg, works with fbcon to act as a framebuffer driver), so why would you want the old VGA (low-res, low-refresh) mode anyway?
For special/embedded systems, they can always leave out that specific driver (ATI/NV/Intel) that does KMS, and keep the old VGA console code, its still in the kernel & available as an option.
You haven't lost anything, you just can't use both at the same time now, e.g. you can't (AFAICT) have the old VGA and the new KMS support builtin to the kernel at the same time.
I believe that a single UI metaphor is essential
In other words, 'one UI to rule them all, and in the darkness, bind them'?
No thanks, if I wanted someone else telling me what UI I should use, I'd still be running Windows.
Choice is good.
Sure - but you're removing that from the context of a person wanting an incredibly light and simplistic system.
I think the GP was referring to a light/fast DE, whether the apps he uses on that DE are light or heavy is really his business. :)
If the DE itself is heavy though, that gets in the way of using heavy apps.
There are many ways to build a GUI, and not many are fatter than Eclipse.
Agreed, its heaviness, and the fact that it didn't provide a GUI designer as I described earlier whereas Netbeans does (though maybe thats changed since I looked at it), is why I've avoided it myself.
However, that 'heaviness' to you & I, means 'useful features' to others (Eclipse's strength seems to be in its plugin system), so I tend to avoid this kind of argument, since I sometimes find myself on the other side of the fence. For example, I favor Qt over Gtk even though the former is much 'heavier' than the latter.
(I use the proprietary nvidia driver)
There's your problem. That thing is notorious for poor 2D performance.
Like the GP, I'm running the latest FOSS ATI driver and speed is not an issue for me either (using KDE 4.3.3).
but 3.5.x ran quite well and was snappy regardless of which graphics chipset
That wasn't my experience, back when I was using an NV card and the driver you are using now.
Of course, it also depends on how you had KDE setup.
There has been a lot of finger pointing about graphics drivers in the 4.x series
KDE4 optionally pushes the graphics envelope further than 3.5 did, and thus tickled some problems (compositing) with the graphics drivers initially. AFAIK, this has been resolved for most users (at least with AMD/ATI), but I don't run with all the eye-candy turned on anyway, so this never affected me.
There are a few KDE devs who seem to the take the "admit no mistakes, push forward!" attitude
The only mistake they made was calling the 4.0 release a '4.0' release, IMO. As far as the UI changes in 4 (Plasma specifically), they were right to do so, even though it meant taking a step backwards temporarily. That was to some degree going to happen anyway as the internal differences between Qt3 and Qt4 were dramatic, so KDE4 was inevitably going to be a much more significant change from KDE3 than KDE3 was from KDE2.
And this all depends on the way people use the DE anyway. For some people KDE 4.3 is still 'worse' than 3.5, yet for others its already 'caught up'. The only missing component for me is the still incomplete conversion of Ksysguard from 3.5 - I still can't use that in KDE4 the way I could in 3.5, but for me at least, thats really just a nitpick.
The payoff is that now KDE4 is even more flexible and configurable than it was before, in terms of how you interact with it. For all of its new 'weird' features, you can *still* set it up to look and act just like 3.5 (which is what I've basically done).
This seems to be the only fundamental difference between KDE and Gnome: Gnome has largely one way of doing things, while KDE is basically a chameleon, its so configurable you can make it look or act like nearly anything else. The argument above us about one-click/double-click for example is utterly irrelevant in KDE, since you can configure it to use either method (and have every KDE-aware app behave in a consistent manner).
Mono isn't a clone of .NET and it was never meant to be.
That certainly explains why Mono's main page refers to itself as 'an open source .NET development framework'... oh wait...
Mono has no need for things like WPF and other Windows-specific libraries.
And that certainly explains why Mono's technologies page has that 3rd column entitled 'Microsoft-compatible stack'... oh wait...
Seriously - why use Eclipse instead of gedit/kate/gvim/take your pick
I don't use Eclipse myself, but the usual reason for IDEs is that they can integrate the GUI development of your app with a WYSIWYG interface. Netbeans can do this for Swing (Java), QtCreator can do this for Qt, Kdevelop can do this for KDE (uses QtDesigner), etc. For development of GUI apps, an IDE like these makes sense.
the CFLAGS where something to the tune of -march=k8 -pipe. Dunno if I had -O2.
I don't believe in over-optimizing CFLAGS;
Yep, Gentoo users who want to avoid headaches are now using something like:
CFLAGS='-O2 -march=native -pipe'
every time Microsoft slips a schedule they're lambasted by Open Source developers and the press
The press is just doing what its supposed to do, and my guess is most FOSS people outside of the Windows ecosystem could care less...
The KDE2.x->KDE3.x wasn't a major change in the interface.
Because it wasn't a major change in the underlying toolkit. Qt3 wasn't fundamentally different from Qt2, only better, whereas the KDE3-to-4 switch was a switch from Qt3 to Qt4, and that was a *massive* change internally. Since they were going to have to rip apart the guts of KDE anyway for this change (necessary to take advantage of the new features of Qt4), they also decided to make some UI changes as well.
Only a moron would talk about how different C# and .NET are from Java.
I agree with the rest of what you say (C# is MS's Java killer), but the C# and Java core languages *are* different from one another, e.g. pointers and unsigned ints for just 2 examples, and to be completely fair, some of the C# differences are (minor) improvements over Java (MS had the advantage of hindsight here).
Anyway, enough differences even in the core languages themselves (never mind the completely *different* supporting libraries that both have) to make the porting of a non-trivial app from one to the other, well, *laughably* non-trivial.
But most importantly: No need for Red Hat? It's either don't use Windows and pay a competitor, or not pay a competitor. It's that simple.
For MS's shareholders it is just about the money, but for everyone else, its not that simple.
All I can say is that MS releasing a 'free' *nix clone of their own will not in any way entice me away from a real FOSS OS, because, of course, free or not, this is still MS we're talking about.
Unless you're idea is that they're going to release this clone under a *real* FOSS license, which ain't going to happen. MS releasing a GPL'd *nix clone? Not in this universe.
it has been shipping the Fast ESP platform on Linux and some other Unix platforms.
Its an enterprise level web-based portal software for businesses, being cross-platform is pretty much a requirement for that category.
When Linus said 'applications' I'm pretty sure he was thinking more along the lines of, say, MS Office, or basically anything the MS has that is Windows-only right now (FAST was already cross-platform before MS bought it).
Linux will never be dependent on Mono.
Well you're right about the Linux kernel, but then again Gnome now *is* dependent on Mono, and a few years ago I wouldn't have thought that would happen, so...
you just port the application to Java, C++ or Go!.
Wait, I've been listening for years to fanbois tell me about how much better, and different, C# is compared to Java, and now you're telling me its a breeze to port any non-trivial C#/.NET app to Java/JVM?
LOL!
Sorry, but you guys can't have it both ways...
Since Mono is a clean-room implementation of .NET and C# (both EMCA standards)
You don't *need* a clean-room implementation of an EMCA standard. Its a *standard*.
Its the 'clean-room implementations' of the non-ECMA-standard software at the top of the Mono software stack that have people concerned, e.g. Winforms & ASP.NET, etc, etc.
And the Community Promise
has so much vague language in it that its only real value is as comic relief.
Seriously, google what the FSF and others think about the language of that 'promise'.
would not hurt for Microsoft do develop and releasy a Unix(y), free software OS alongside of Windows. ... Everybody would probably be happy.
Except MS's shareholders...
Deliberately create, to some degree, a competitor to their current cash-cow and *not* make any money off of it? Seriously?
Patents were made to spawn innovation - bypassing secretive guilds by incentivizing the opening of knowledge to public domain in exchange for a limited time monopoly. Projects and society are way too fluid now to keep many inane details secret anyway.
The patent concept was also invented with the idea of the physical widget in mind, at a time when making things was an expensive proposition. A real physical 'thing' that had to be *manufactured*. The goal: make companies more likely to make the massive investments in R&D, time, effort, material and capital acquisitions, tooling, retooling, e.g. making the tool that made the tool that finally made the widget itself, and then the final manufacturing process, renting the floor space, hiring the workers, setting up the 'assembly line'. For many 'real widgets' this is all expensive as hell. A limited monopoly was seen as a way to offset those expenses. As far as that all goes, it kinda makes sense, although we could always quibble about the length of the granted monopoly, or other relatively minor things, but...
Where is the equivalent massive expenditures involved in creating software? Software is not physical, its electronic, ephemeral (and never mind also being closer to an expression of mathematical algorithms than to something you see and hear and feel and touch like a physical thing). Most of the 'manufacturing process' goes on in the coders' heads, not on a shop floor.
And the 'worst-case' scenario (or best-case depending on your pov): Capitol investment? One cheap beige-box computer. Raw materials? Caffeine & cold pizza. Infrastructure? Mom's basement.
As soon as you look at the history of the patent and *why* it was created, the more today's picture seems out of focus. Its goal was never to simply reward the one who 'got there first', its original purpose was to help offset the real costs of inventing, so it would be financially worthwhile for someone to even try to do it at all. This is why it was simply a bad idea to apply it to a non-physical widget, because the real and practical reasons for doing this with physical widgets, do not really apply to software.
And don't even get me started on 'business method' patents... grrr...
The examiner has to make a prima facie case of unpatentability in order to reject a claim.
So the burden of proof on the overworked, underpaid (and possibly incompetent) examiner is thus set very high, possibly too high.
If the examiner can't substantiate such a case, the application gets allowed, and the applicant gets a patent.
Who is now free to use that patent against others like a bludgeon, and the burden of proof for the *defendant* ends up high as well, and even when they can do what the examiner could not (find prior art), they've already *lost* anyway, at least from a business's bottom-line-oriented (expense) point-of-view.
Only when the examiner makes a prima facie case does the burden shift to the applicant to either ...
What burden? They just keep rewording and resubmitting it until they simply wear down the examiner...
Are (most) patent attorneys paid per application *attempted*, or per application *approved*, or strictly per hour?
What about companies with in-house staff? They've got nothing better to do than to keep chipping away at the USPTO, since every patent in their arsenal becomes worth the trouble in the case of a nuclear patent showdown with a rival...
I know Slashdot loves to exaggerate things in headlines, but this is absurd.
No sir, this is not absurd... this *is* Slashdot!
I'd guess the editors consider any TFA that generates 600+ posts to be a "good day's work", irrespective of the presence or absence of exaggeration and/or absurdity, *especially* if they don't have to invent the absurdity themselves, but merely link to it...