It's really necessary for something to be done about the current environment for IT people. I've been hit by this at several jobs and it really sucked. The worst are integration companies, where you are paid a salary but billed to the client hourly. Deadlines and workloads are setup such that the "engineer" is expected to work 60 - 80 hour weeks for a flat rate salary while the company is being paid for the service, often at an "overtime" rate.
And woe be the guy who isn't back in the office again at 8 AM sharp after working on a project until 1:00 am the day before. I've been threatened with losing pay and even possible termination for just that very thing.
The FUD machines are still running at full speed and spewing loads of irrelevant lies, damned lies, statistics, and general crap. It's done because it is rather effective on the uninformed masses of managers who have little depth of knowledge and simply want "safety".
Seriously, the Linux kernel is in no danger of imploding any time soon. The community is rather strong and resilient. Really, the big difference is that the development process is visible, as opposed to proprietary software houses where these conversations are inside the walls of the company. The debates we're hearing about are a normal part of development and will eventually lead to a solution that works for everyone.
Desktop Linux vs. "Server Linux" is a total non-issue at the kernel level. The userland tools and interfaces are far more important, and really the only real roadblock right now is a few hardware manufacturers' active resistance to working with free software. This isn't so much a conspiracy to lock out certain operating systems, it's just a way to manage their obselecence cycles to ensure future sales. After all, if customers can keep using that printer until it actually wears out then quarterly profits will see no replacement sales bump when the next Windows release comes out.
This resistance is starting to fray around the edges, and we can see the evidence in AMD/ATI's starting to open up chip specs and Dell's entry into the desktop Linux market. It's beginning to become a non-viable business model to actively impede interoperability with open source software.
Bundling is the removal of choice, and unbundling does not preclude offering the OS as an OPTION that can be pre-installed. The key is to provide a choice for the customer to decide what, if any, OS they want to purchase with new hardware.
It will not scare away anyone who is willing to follow the license terms, but will make those who believe that GPL'ed code is a sort of "freeware" change their attitude fast.
If they are unwilling to distribute source, they shouldn't use GPL covered code, period. Use BSD or license proprietary code instead.
GPL is pretty clear that whoever is distributing the binaries must also distribute the source themselves. It's not acceptable to rely on the "upstream" to do so.
Autoconfig is a nice default for something that "just works" without much need for an admin to plan out the network, and DHCP is great for tighter control where needed. What's wrong with having both options available?
Really, I can do anything in Pascal that I can in C/C++, just differently. I like the more "rigorous structure" and cleaner syntax of Pascal - if it compiles, it probably will run too. I find a bit smaller bug count in Pascal code than in C. Maybe just because it makes me settle down a bit and put variable declarations and stuff together in a VAR block instead of accidentally just declaring them where I think it's needed like you can do in C, so scope problems are reduced.
And Pascal is a wee bit nicer for string handling.
Oh, they very well might get jail time for this case. I saw a veiled threat in their notice to Judge Kimball...
"PLEASE TAKE FURTHER NOTICE that contempt proceedings may be initiated against any party who participates in any violation of the automatic stay, and, pursuant to the provisions of the Bankruptcy Code, the Bankruptcy Court may award actual damages, including costs and attorneys' fees (and, in appropriate circumstances, punitive damages) to compensate the Debtors for loss arising out of violations of the automatic stay."
In other words... "Judge, you will put this case on hold, or we'll sue YOU and press contempt charges!"
It's the ultimate in guts to write threats like that to a Federal judge. They can REALLY find a way to mess up your life, and Kimball is a REALLY good one.
Cross-post from Groklaw...
I did a quick Google of "bad faith" in regards to bankruptcy filings,
and there is apparently precident regarding exactly the same situation as SCO is
in.
Using bankruptcy just as a tool to thwart other litigation is apparently a BIG
no-no. From a non-authoritative source:
http://touchngo.com/lglcntr/usdc/bnkrptcy/briefs/bnk45.htm
"One area ripe for a bad faith dismissal is when the debtor is using a
bankruptcy filing as a litigation tactic to either forestall litigation or seek
a forum perceived to be more friendly. In Marsch, the court upheld a 'bad faith'
dismissal where the chapter 11 petition was filed solely to delay collection of
a judgment and avoid posting an appeal bond where the debtor had the financial
means to pay the judgment."
Also, in addition to dismissing the bankruptcy case, the bankruptcy courts may
well impose the "nuclear" sanction - barring SCO from asserting
another bankruptcy claim in the future. This would leave them totally exposed
to the full wieght of any other judgements, with no way out at all - not even
Chapter 7 liquidation. In other words... "you're on your own,
Darl..."
Is anyone with any expertise in bankruptcy proceedings around to help the
community figure out exactly how this works?
Something tells me the bankruptcy filing is not going to fly for long, but may
expose SCO's legal team to some serious malpractice liability.
And... maybe after this little road bump is resolved we'll finally see Kimball
bring some real sacnctions down on the SCO side too.
This is just getting beyond ridiculous.
This sure looks like the beginning of the end-game scenerio for SCO. It will have zero effect on the Novell claims, since they are "equitable" and basically just amount to an embezzelment/conversion charge, not a "debt". It's a return of improperly held property, so bankruptcy doesn't provide any cover there.
Actually, it may make it easier for Novell in a couple of weeks to force it into a Chapter 7 liquidation proceeding instead, since the case will already be in the Bankruptcy Courts.
They are SO toast now.
Really, memory and CPU bottlenecks are not the biggest issue right now. The problem is and has been storage speed. It doesn't matter if we can crunch bits faster on the mainboard if we can't get them in and out to begin with.
Memory and CPU speeds are skyrocketing and hard disk performance has stayed rather flat for years. Until drive performance catches up we'll still be waiting forever for the OS to boot up or apps to load.
It happened to me with Windows 2000. A MS update called "Update Rollup 1" really badly broke ODBC connectivity with MS Access 2000 and back-end databases. It took a week to figure out why I couldn't relink tables (the dialog would just hang), and the problem was only resolved by uninstalling the update.
Note that this was a case where a MS update broke another MICROSOFT product, and I had to lose a week of real work to resolve the issue.
Really, this only has application to companies in the business of selling devices with embedded Linux and to distribution providers. It really doesn't hit the end user, as they don't participate in the act of "distribution" that the GPL restricts.
Oh - as I am wont to say, the BSD license is "libertarian" in its general outlook whereas the GPL is "socialist" in its outlook, and of course proprietary EULAs are almost exclusively "fascist" in theirs.
How is blocking ads really any different from going to the bathroom during commercial breaks when watching a TV program? It seems to me as if it's exactly the same thing.
I concur fully with this on simple consumer protection grounds, and strongly disagree with the other posters who claim it will simply enable copycat implementations. Here's why:
It is trivial to provide a generic enough INTERFACE to abstract away all the dirty details of the actual implemntation of any piece of code or hardware. As a practical example, think of programming to a library as is commonly done now. Just because you have the.h (header) files that tell you what functions are available to call, you do not have source code for the.c (or.cpp) files that detail HOW they do their job. You would still have to do all the same work as the initial author (or hardware designer) to recreate an actual implementation.
Further, the manufacturers are protected already under patent and copyright laws against competitors attempting to recreate their products. There is nothing more than a slight speed bump provided by a "hidden" interface that a competitor or other person doing a full-blown reverse engineering effort will simply go past. Worst case scenerio is that the competitor can be compatible with your implementation, by building to the same interface, which really just helps the consumers and creates a de-facto standard and forces competition to go back to where it belongs: a contest based on quality and price.
Further, since such a regulation would apply equally to all players in the market nobody would gain an advantage or disadvantage from its existance. On balance, the entire market and end users will gain substantially and only competitors in the market with an intent to defraud or impose their will upon the consumer will lose out a bit and be forced to compete on merit once more.
It's actually pretty simple when you think about it. The legal profession long ago abandoned the principle of "rule of law" and substituted in its place "rule of lawyer". This turned the entire judicial branch of the government into thier own money making machine.
They're supposed to be professionals, so go they just need to bed earlier and get up in time for the hearing. Getting up a couple hours early is NOT an "undue hardship" by any stretch of the imagination. Just bill the client the "off hours" rate multiplier and be done with it.
Yeah... but we can dream. It would be SO COOL to be able to define a custom CPU instruction to shoot a block of bytes through a hardware JPEG encoder...
I'd like to see something like an FPGA onboard with a compiler (or device driver model) that can allow us to take some time consuming things such as CODECs and push them off into hardware.
Lawyer-up and sue them for the copyright infringement. BTW... what's the "statutory damages" for such a violation? And... with a good enough (or evil enough) lawyer, you can push for "class action" status and smack them for everyone else they do this with...
Just a thought...
Slashdot Mirror
It's really necessary for something to be done about the current environment for IT people. I've been hit by this at several jobs and it really sucked. The worst are integration companies, where you are paid a salary but billed to the client hourly. Deadlines and workloads are setup such that the "engineer" is expected to work 60 - 80 hour weeks for a flat rate salary while the company is being paid for the service, often at an "overtime" rate.
And woe be the guy who isn't back in the office again at 8 AM sharp after working on a project until 1:00 am the day before. I've been threatened with losing pay and even possible termination for just that very thing.
Guess I'm the only one left who uses CAD to make network drawings nowadays?
The FUD machines are still running at full speed and spewing loads of irrelevant lies, damned lies, statistics, and general crap. It's done because it is rather effective on the uninformed masses of managers who have little depth of knowledge and simply want "safety".
Seriously, the Linux kernel is in no danger of imploding any time soon. The community is rather strong and resilient. Really, the big difference is that the development process is visible, as opposed to proprietary software houses where these conversations are inside the walls of the company. The debates we're hearing about are a normal part of development and will eventually lead to a solution that works for everyone.
Desktop Linux vs. "Server Linux" is a total non-issue at the kernel level. The userland tools and interfaces are far more important, and really the only real roadblock right now is a few hardware manufacturers' active resistance to working with free software. This isn't so much a conspiracy to lock out certain operating systems, it's just a way to manage their obselecence cycles to ensure future sales. After all, if customers can keep using that printer until it actually wears out then quarterly profits will see no replacement sales bump when the next Windows release comes out.
This resistance is starting to fray around the edges, and we can see the evidence in AMD/ATI's starting to open up chip specs and Dell's entry into the desktop Linux market. It's beginning to become a non-viable business model to actively impede interoperability with open source software.
Bundling is the removal of choice, and unbundling does not preclude offering the OS as an OPTION that can be pre-installed. The key is to provide a choice for the customer to decide what, if any, OS they want to purchase with new hardware.
It will not scare away anyone who is willing to follow the license terms, but will make those who believe that GPL'ed code is a sort of "freeware" change their attitude fast.
If they are unwilling to distribute source, they shouldn't use GPL covered code, period. Use BSD or license proprietary code instead.
GPL is pretty clear that whoever is distributing the binaries must also distribute the source themselves. It's not acceptable to rely on the "upstream" to do so.
fork(him);
Autoconfig is a nice default for something that "just works" without much need for an admin to plan out the network, and DHCP is great for tighter control where needed. What's wrong with having both options available?
Really, I can do anything in Pascal that I can in C/C++, just differently. I like the more "rigorous structure" and cleaner syntax of Pascal - if it compiles, it probably will run too. I find a bit smaller bug count in Pascal code than in C. Maybe just because it makes me settle down a bit and put variable declarations and stuff together in a VAR block instead of accidentally just declaring them where I think it's needed like you can do in C, so scope problems are reduced.
And Pascal is a wee bit nicer for string handling.
Oh, they very well might get jail time for this case. I saw a veiled threat in their notice to Judge Kimball...
"PLEASE TAKE FURTHER NOTICE that contempt proceedings may be initiated against any party who participates in any violation of the automatic stay, and, pursuant to the provisions of the Bankruptcy Code, the Bankruptcy Court may award actual damages, including costs and attorneys' fees (and, in appropriate circumstances, punitive damages) to compensate the Debtors for loss arising out of violations of the automatic stay."
In other words... "Judge, you will put this case on hold, or we'll sue YOU and press contempt charges!"
It's the ultimate in guts to write threats like that to a Federal judge. They can REALLY find a way to mess up your life, and Kimball is a REALLY good one.
That suit looks very good on him.
Cross-post from Groklaw... I did a quick Google of "bad faith" in regards to bankruptcy filings, and there is apparently precident regarding exactly the same situation as SCO is in. Using bankruptcy just as a tool to thwart other litigation is apparently a BIG no-no. From a non-authoritative source: http://touchngo.com/lglcntr/usdc/bnkrptcy/briefs/bnk45.htm "One area ripe for a bad faith dismissal is when the debtor is using a bankruptcy filing as a litigation tactic to either forestall litigation or seek a forum perceived to be more friendly. In Marsch, the court upheld a 'bad faith' dismissal where the chapter 11 petition was filed solely to delay collection of a judgment and avoid posting an appeal bond where the debtor had the financial means to pay the judgment." Also, in addition to dismissing the bankruptcy case, the bankruptcy courts may well impose the "nuclear" sanction - barring SCO from asserting another bankruptcy claim in the future. This would leave them totally exposed to the full wieght of any other judgements, with no way out at all - not even Chapter 7 liquidation. In other words... "you're on your own, Darl..." Is anyone with any expertise in bankruptcy proceedings around to help the community figure out exactly how this works? Something tells me the bankruptcy filing is not going to fly for long, but may expose SCO's legal team to some serious malpractice liability. And... maybe after this little road bump is resolved we'll finally see Kimball bring some real sacnctions down on the SCO side too. This is just getting beyond ridiculous.
This sure looks like the beginning of the end-game scenerio for SCO. It will have zero effect on the Novell claims, since they are "equitable" and basically just amount to an embezzelment/conversion charge, not a "debt". It's a return of improperly held property, so bankruptcy doesn't provide any cover there. Actually, it may make it easier for Novell in a couple of weeks to force it into a Chapter 7 liquidation proceeding instead, since the case will already be in the Bankruptcy Courts. They are SO toast now.
Really, memory and CPU bottlenecks are not the biggest issue right now. The problem is and has been storage speed. It doesn't matter if we can crunch bits faster on the mainboard if we can't get them in and out to begin with. Memory and CPU speeds are skyrocketing and hard disk performance has stayed rather flat for years. Until drive performance catches up we'll still be waiting forever for the OS to boot up or apps to load.
It happened to me with Windows 2000. A MS update called "Update Rollup 1" really badly broke ODBC connectivity with MS Access 2000 and back-end databases. It took a week to figure out why I couldn't relink tables (the dialog would just hang), and the problem was only resolved by uninstalling the update. Note that this was a case where a MS update broke another MICROSOFT product, and I had to lose a week of real work to resolve the issue.
Really, this only has application to companies in the business of selling devices with embedded Linux and to distribution providers. It really doesn't hit the end user, as they don't participate in the act of "distribution" that the GPL restricts. Oh - as I am wont to say, the BSD license is "libertarian" in its general outlook whereas the GPL is "socialist" in its outlook, and of course proprietary EULAs are almost exclusively "fascist" in theirs.
How is blocking ads really any different from going to the bathroom during commercial breaks when watching a TV program? It seems to me as if it's exactly the same thing.
I concur fully with this on simple consumer protection grounds, and strongly disagree with the other posters who claim it will simply enable copycat implementations. Here's why: It is trivial to provide a generic enough INTERFACE to abstract away all the dirty details of the actual implemntation of any piece of code or hardware. As a practical example, think of programming to a library as is commonly done now. Just because you have the .h (header) files that tell you what functions are available to call, you do not have source code for the .c (or .cpp) files that detail HOW they do their job. You would still have to do all the same work as the initial author (or hardware designer) to recreate an actual implementation.
Further, the manufacturers are protected already under patent and copyright laws against competitors attempting to recreate their products. There is nothing more than a slight speed bump provided by a "hidden" interface that a competitor or other person doing a full-blown reverse engineering effort will simply go past. Worst case scenerio is that the competitor can be compatible with your implementation, by building to the same interface, which really just helps the consumers and creates a de-facto standard and forces competition to go back to where it belongs: a contest based on quality and price.
Further, since such a regulation would apply equally to all players in the market nobody would gain an advantage or disadvantage from its existance. On balance, the entire market and end users will gain substantially and only competitors in the market with an intent to defraud or impose their will upon the consumer will lose out a bit and be forced to compete on merit once more.
It's actually pretty simple when you think about it. The legal profession long ago abandoned the principle of "rule of law" and substituted in its place "rule of lawyer". This turned the entire judicial branch of the government into thier own money making machine.
They're supposed to be professionals, so go they just need to bed earlier and get up in time for the hearing. Getting up a couple hours early is NOT an "undue hardship" by any stretch of the imagination. Just bill the client the "off hours" rate multiplier and be done with it.
Yeah... but we can dream. It would be SO COOL to be able to define a custom CPU instruction to shoot a block of bytes through a hardware JPEG encoder...
I'd like to see something like an FPGA onboard with a compiler (or device driver model) that can allow us to take some time consuming things such as CODECs and push them off into hardware.
Lawyer-up and sue them for the copyright infringement. BTW... what's the "statutory damages" for such a violation? And... with a good enough (or evil enough) lawyer, you can push for "class action" status and smack them for everyone else they do this with... Just a thought...
Nice effort, but why not just use a couple blade servers in a chassis?
I, for one, welcome our new SP1 overloards. (Not really, but it will generate a whole shitload of billable hours).