Indeed, the VisionProbe II sounds very similar to some Abatron hardware (a BDI2000, IIRC) I was using to do kernel debugging via GDB a few years ago when working at MontaVista.
And speaking of -- there are plenty of companies which have been in the embedded Linux market longer than Wind River, and have much more Linux-friendly engineering staffs. MontaVista is one of these, Lineo another... wouldn't it make sense for your embedded Linux business to go to a company that's been focused around Linux from the start rather than just for the last few months?
Libertarians always say they don't believe in handouts, so why should I give EFF a handout then?
Libertarians don't believe in handouts funded by individuals who didn't explicitly and personally agree to provide those handouts. So, say, if money that was taken from me via taxes is being given to the League of Gay Midget Eskimos without my consent, that's a bad thing. I may be more than happy to donate to said League if it were my choice -- but being forced to do it at the risk of men with guns coming and putting me in jail is a different matter.
The EFF is the same way. I don't believe in enforced handouts to the EFF from folks who don't support them -- if you don't like the EFF, you shouldn't be forced to donate to them. On the other hand, if you believe that donating to the EFF is something you wish to do -- perhaps even something which is aligned with your own enlightened self interest -- then you should be every bit as free to do that as to donate to the Gay Midget Eskimo fund. Which is to say, very.
It's not just groupthink. Some of us have actually been involved in Linux kernel development, and have some sort of an idea of what the process looks like -- and thus, what it would take for the amounts of code SCO refers to to make it into the kernel.
Do you know that the fellow you replied to is not such an individual?
Do you know if I am?
It must be nice to participate in totally unfounded assumptions regarding the evidence your opponent is basing their decisions on.
OTOH, if SCO's "evidence" is debated and publicly debunked, that provides more (and easier-to-access) ammo for those who'll be opposing them both in court and in the arena of public PR.
They're going to be able to twist the more gullible media and investment types no matter what -- might as well have the rest of the discussion out in public too, such that those serious about understanding what's *really* going on have access to all the relevant information involved.
I just reread my post again to figure out how it is you think I'm saying their failure to abide by the GPL is justified.
I don't. What I do say is that they're between a rock and a hard place -- either they break their contract with Broadcom or they commit large-scale copyright violation (of the Linux kernel) or they withdraw their product. All of these paths *suck*, and in a big way. Breaking their contract with Broadcom is illegal. Committing large-scale copyright violation of Linux is illegal. Withdrawing their product... well, it ain't illegal, but it most likely means a whole bunch of people losing their jobs, and is a good PR case for folks to use who are trying to scare customers away from the embedded Linux houses (one of which I used to work for).
My hope is that they'll be able to work out an agreement with Broadcom under which they can distribute the relevant bits; that's probably the closest thing available to an everybody-wins solution.
The reason they're not releasing the drivers is (quite possibly) that they can't, due to NDAs and such with Broadcom -- not that they're trying to minimize their competition's barrier to entry.
If this is the case, however, then they're between a rock and a hard place -- since they've got this code statically linked, they don't qualify for Linus's modules-aren't-derivative-works exemption.
Further, this is quite possibly something that came up later in the development cycle than when the which-OS-do-we-use decision went through; it's easy to just be too heavily committed to make a switch partway through. (And then, there are other factors -- maybe they had folks on staff already familiar with using Linux for embedded work but who would need to retrain to be familiar with kernel hacking the BSDs, or perhaps they already had a contract with a Linux vendor to provide them with an embedded development environment, support, and so forth).
What I'm saying is that "oh, well then, we'll just use BSD" isn't always such an easy decision to make.
What's the big deal anyway? The thing uses proprietary hardware, so in order to reproduce it, you'd also have to have the masks to make the chips anyways
Err, well, no.
It actually uses, for instance, a set of chips manufactured by Broadcom. Anyone else building an embedded system and looking to use those chips -- or writing drivers for PC hardware based on those chips -- would have a great deal of use for these drivers.
The difference is that when an airplane runs out of gas it tends to crash from a much higher altitude, a person falling off a Segway is getting off much easier then a pilot with a dry tank.
Airplanes can glide. A small plane can use a flat, straight highway as a landing strip in a pinch. An airplane pilot at a good height without any running motors has (compared to someone on a suddenly-toppling Segway) plenty of time to figure out how to recover from their situation.
I'll grant, however, that given the choice, I'd probably rather be on the Segway.
But I doubt that the whole desktop system based on MIPS would be cheaper than performance-equal x86 ones.
Okay, I thought I tried to make this point earlier... but maybe not.
For a low-end workstation, who the hell cares about "performance-equal" any more?
Low-end workstations all perform more than well enough to browse the web, read email, run a word processor or run remote apps off a server. Additional performance no longer really buys additional relevant functionality in the low-end workstation market... which is why things like silent running become more important than speed.
I'll grant that a MIPS-based line of low-end workstations would need a substantial production quantity to hit the right price point -- but *given* that (and presuming one is building ones' own components), the additional functionality (ie. very low power consumption/heat usage) is potentially enough to make them competitive even if they aren't performance-equal.
The *original* subject which spawned this thread was Intel being scared.
That said, part of my point was potential for bleedover. If low-end workstations become, as a rule, Linux based (and thus have less software requirements tying them to a given architecture), it's all the easier for them to go over to MIPS -- at which point the manufacturers can do customer-friendly things like... say... leave out the fans, and have an almost silent-running system (particularly in the case of diskless systems, where the "almost" can be discarded, or some of Seagate's hard drives designed with low noise levels in mind).
One of the useful things about C is that it can be viewed as an abstract version of assembly language -- it's somewhere between "easy" and "trivial" to look at just about any chunk of code and *know* how an unoptimized compiler would implement it. Correspondingly, C encourages a programmer to think in terms not of abstractions, but in terms of what precicely the machine itself is actually doing when running their code. If C had been written with some of the safety features of higher-level languages in mind, I suspect that some varieties of low-level coding -- writing drivers, for instance -- would be negatively impacted (whadaya mean I can't write to this arbitrary pointer value?)... and as long as you *can* write to an arbitrary memory location, your program can still do Bad Things if subverted.
Higher-level languages -- and Ada is among them -- lose this what's-going-on-under-the-hood focus, and tend more towards *forcing* the user to work in terms of abstractions rather than dropping down into high-level-assembly mode when appropriate. I'll agree that thinking in abstractions is a Good Thing in a great many cases -- but writing low-level code just ain't one of them, and that's exactly what C is good for.
Having your compiler be able to choose between "safe and unsafe string types", for instance, means that you've got a high-enough level language that the compiler actually understands what a string is. This (a "string") is an abstraction. C programs don't deal with abstractions on that level -- they deal with null-terminated arrays of 8-bit values, not with "strings". The compiler doesn't know that array-of-8-bit-values $FOO is a "string" and can have its underlying representation changed at will, but that array-of-8-bit-values $BAR happens to be in a memory location which corresponds to the internal memory of some PCI device on the system and must be represented *exactly* as the programmer indicates. Use an abstract language if you want a compiler that understands such things... C is not that language, and it's *intentionally* not that language, because having a sufficiently low-level language is Useful And Good. (Besides, having the compiler choose between multiple internal representations for the same code would be evil, because it means the same code would have different calling conventions based on compiler flags).
It's been years (about 6 of them, I think) since I've written any Pascal, and my memory span is measured in months if not weeks... so I'm going to not touch that thing, except to mention that I'm quite sure every major Pascal compiler vendor had extensions to implement pointer arithmetic on account of the language being difficult to express some algorithms in without it.
And by the way, if this is a whole big long collection of unfocused rambling, I'm *really* short on sleep right now, and am just about to go hit the sack rather than continuing to blather on about things while my brain's too tired to work.
Tsk, tsk. Repetition as a means of driving a point home is an established and well-respected tool of debate. The one-line summary doesn't carry the *weight* of the expanded version -- which is precicely the effect I was going for.
Cleaner, more readable code is probably loaded with bugs or lacking in features because it hasn't been around long enough to have all the disgusting hacks and patches applied to it that are required for extended use in the real world.
What this means is that you haven't spent time in the real world on a programming team with an architect who believes in constant, aggressive refactoring -- and is willing to bully the suits (and the coders, and everyone else) as much as necessary to be sure it gets done.
I'm on such a team. There're ugly hacks in our code, sure -- but they don't last more than a month or so before getting refactored out.
Oooh, good call. Fortunately, I've got just the tool for reducing this to its least redundant representation.
S -> 1 a u d i t 2 b u g f i x 2 3 d _ f 4 5 6 7 8 9 10 11 m p l y _ G o 12 _ S 5 f f.
1 -> 10 4 11 13 _ 8 _ 2 -> 9 1 3 -> a d 4 -> e a 5 -> t u 6 -> r e 7 -> s _ 8 -> t o 9 -> . \n 10 -> C 14 a n 13 , _ m o 6 _ 6 3 a b 14 _ c 12 e _ i 7 11 -> s i 12 -> o d 13 -> e r 14 -> l e
Consider that an object lesson in why denormalization is sometimes a Good Thing.:)
A good replacement for C, eh? How 'bout C? Or, say, C?
Honestly, though: For low-level programming, there *is* no good replacement for C, for a simple reason: the same power that makes it dangerous is also the power that makes it useful. For high-level programming, there are lots of good replacements -- and you just mentioned, and wrote off, two of the best of them.
Java is getting better (witness the presence of the NIO API in 1.4), and I've got strong hopes for C# and its kin -- but part of what makes C# so useful is its simple API for access to C libraries, something that Java makes much harder. That said, for almost all of the high-level programming I do, I use Python (except at work, where I don't always get to pick; in the cases where I don't have the choice, I write Java).
Sure, Python and Java aren't suitable for low-level work -- but that's what C is good for. And since calling from Python down to C is simple, writing optimized versions of performance-sensitive routines is easy, in the rare event that it actually needs to be done (which has, in my five or so years of writing Python, happened all of once, when I needed some efficient drawing routines which were most readily available from a C library without preexisting python bindings).
Compiling Java to native code with GCJ also decreases the startup-time and runtime performance penalty without sacrificing type-safety -- and works for applications using an increasingly large subset of the available APIs.
Scheme is another language that many folks are too quick to write off. Not only does the language have the expected type-safety goodness -- but compiled scheme can be *very* fast. (On the down side, the lack of a useful standard runtime library is very disappointing).
So, yes, for high-level stuff, there are lots of alternatives... but what are you going to write your Python interpreter or low-level libraries in? For some jobs, there's still no good replacement for C. (Further, I'm not by any means convinced that low-level work *should* be done in an OO language... but that's a different conversation).
Cleaner, more readable code is easier to audit. Cleaner, more readable code is easier to bugfix. Cleaner, more readable code is easier to add features to. Cleaner, more readable code is simply Good Stuff.
Corporations exist to do what their shareholders want them to, and to fulfill the purpose specified in their articles of incorporation. Usually what the shareholders want is to make money... but then, we don't know who Eolas's shareholders are, much less what they want. Consequently, they could well be out for vengeance.
I could see these arguments applied to W.R. Grace and PG&E, but SCO c'mon.
Eh?
SCO is trying to discredit the product of thousands of man-years of hard work, many of which were put in voluntarily as nothing more than a labor of love. They're attempting to prevent me from using code I helped write in my own workplace without paying them an unreasonable fee. Because I'm one of those open source developers whose ethics, practices and motivations they're calling into practice, they're attacking me personally -- and thousands and thousands more like me besides -- without evidence, without just cause, without any motivation besides profit.
Granted, I've not been following the news lately (and haven't been in California for over a year now), but I'm not aware of anything PG&E has done that's even nearly as severe.
That you don't have the cojones to swallow your pride and tough it out for them. Sure pride and ideals have their place, but so does humility and sacrifice.
Funny, I thought suborning one's ideals to keep receiving that paycheck was the choice indicative of the lack of cojones.
Humility and sacrifile are by all means good qualities, I'll grant -- but something's very wrong if they're being used as an excuse to participate in something which is morally bankrupt.
The "I'm just a grunt" defense has been discredited for war crimes... why, again, does it apply here?
I'm not saying Damage doesn't have the right to question the integrity of any former SCO employees, just that they shouldn't be prejudging them when there may be extenuating circumstances.
Can you really argue with that last statement?
No, I can't. Someone else here posted a link to the resume of one of SCO's lead open source developers, who mentioned that he may be soon looking for a new job doing open source work. Looking over it, I was almost tempted to send him an email asking if he'd consider applying with my last employer -- MontaVista Software -- as he looks like a generaly good fellow and would probably fit in well there.
I'm not going to say there's anything wrong about Damage's stand, though -- besides that it unnecessarily prevents them from potentially being able to hire what few talented and yet non-morally-bankrupt employees SCO has left. That's their loss, though, and if they think that they'd rather make a political point (and not need to sift through the resumes from folks at SCO *without* said extenuating circumstances), such is their choice to make.
(Why "what few" talented yet non-morally-bankrupt employees? Because the most talented folks are the ones who have the easiest time finding new work, even in a down market, and so who have the least disincentive to leave when the company's actions offend them. Also, typically, a good chunk of such folks are idealistically motivated; many of my better coworkers at MontaVista were there not only because they liked the paychecks but because they wanted to help improve open source software).
Having to pay two car payments (rather than buying a $500 used commute vehicle or two) or substantial consumer debt is indicative of bad choices; and in a two-parent household, needing childcare implies that both parents are working -- so if only *one* of them gets their pay cut to $25k/yr, that's not so bad (and if it's via complete loss of income for one of those two that the income is cut to $25K/yr, childcare is no longer needed as the nonworking parent can provide childcare {him,her}self). Likewise, student loans are avoidable -- I paid my own way through college without a single loan, as did my father. One student I know just made $15K over the last summer selling books door-to-door -- more than enough to finance a year of studenthood (my expenses were $9k/yr, and could have been less had I been more diciplined with regards to my spending).
Having a family changes things, that I'll grant -- but nonetheless, being unable to have two cars that cost more than one has in available cash or being unable to afford the goodies that result in "consumer debt" or needing to have ones' kids pay their own way through school is by no means an impossible, life-shattering level of hardship.
My income, excluding hitherto worthless stock options, has never been more than $23K/yr; despite that, I've been able not only to pay my own way but to make substantial fiscal contributions to the wellbeing of those close to me (including more than one family with children). Living cheaply takes some dicipline, no doubt -- but it's entirely possible for those willing to make the appropriate compromises. As for those who aren't so willing -- the situations they put themselves in are thus their own fault, and I see little cause for sympathy.
Being unwilling to move around the country as needed is another expensive lifestyle choice. If someone chooses to live somewhere with a cost of living they're unable to support, I hardly see that as a reason for sympathy either. (And yes, I *have* moved halfway across the country myself, with cost-of-living differences among prime motivating factors).
I'd rather kill a human being rather than let him steal my DVD player
From where I stand, it's not the DVD player that's important. To violate the sanctity of another's home is wrong -- far more deeply so than the dollar value of whatever property may be lost indicates -- and the protection of one's home and family is right.
Some of my friends live out in the country. When folks come over, they leave their keys on their dashboards and their car doors unlocked, so that if anyone needs to move their car they can do so. Vehicle theft is unheard of -- because it's taken as given that out there, half an hour away from any police force, everyone is armed. It goes without saying that they leave their doors unlocked, as well; home invasion is another thing that simply doesn't happen there.
The level of comfort from living in a society with that level of trust -- to be able to leave one's property out in the open, unprotected -- may be something you don't know; perhaps you live in big metropolitan area somewhere. In any event, I'm more than happy to pay the price of a few foolhardy criminals -- "individuals" lacking respect for their fellow members of society -- being shot while stealing a DVD player.
And by the way, one of my best friends once spent several years in jail for a crime which, had he committed it in Texas, the person he had committed it against could have shot him for[*]. He's a good person, and I value his life -- but that makes me no less convinced that it would still have been morally just for the person whose property rights he violated to have defended said rights by force.
[*] "for", in this case, meaning to stop him from committing said crime or escaping from it; presuming that the person against whom the crime was committed reasonably believed he could not safely stop it using lesser means -- which, being that my friend is/was a martial artist, is likely.
Slashdot Mirror
Indeed, the VisionProbe II sounds very similar to some Abatron hardware (a BDI2000, IIRC) I was using to do kernel debugging via GDB a few years ago when working at MontaVista.
And speaking of -- there are plenty of companies which have been in the embedded Linux market longer than Wind River, and have much more Linux-friendly engineering staffs. MontaVista is one of these, Lineo another... wouldn't it make sense for your embedded Linux business to go to a company that's been focused around Linux from the start rather than just for the last few months?
Libertarians always say they don't believe in handouts, so why should I give EFF a handout then?
Libertarians don't believe in handouts funded by individuals who didn't explicitly and personally agree to provide those handouts. So, say, if money that was taken from me via taxes is being given to the League of Gay Midget Eskimos without my consent, that's a bad thing. I may be more than happy to donate to said League if it were my choice -- but being forced to do it at the risk of men with guns coming and putting me in jail is a different matter.
The EFF is the same way. I don't believe in enforced handouts to the EFF from folks who don't support them -- if you don't like the EFF, you shouldn't be forced to donate to them. On the other hand, if you believe that donating to the EFF is something you wish to do -- perhaps even something which is aligned with your own enlightened self interest -- then you should be every bit as free to do that as to donate to the Gay Midget Eskimo fund. Which is to say, very.
It's not just groupthink. Some of us have actually been involved in Linux kernel development, and have some sort of an idea of what the process looks like -- and thus, what it would take for the amounts of code SCO refers to to make it into the kernel.
Do you know that the fellow you replied to is not such an individual?
Do you know if I am?
It must be nice to participate in totally unfounded assumptions regarding the evidence your opponent is basing their decisions on.
OTOH, if SCO's "evidence" is debated and publicly debunked, that provides more (and easier-to-access) ammo for those who'll be opposing them both in court and in the arena of public PR.
They're going to be able to twist the more gullible media and investment types no matter what -- might as well have the rest of the discussion out in public too, such that those serious about understanding what's *really* going on have access to all the relevant information involved.
I just reread my post again to figure out how it is you think I'm saying their failure to abide by the GPL is justified.
I don't. What I do say is that they're between a rock and a hard place -- either they break their contract with Broadcom or they commit large-scale copyright violation (of the Linux kernel) or they withdraw their product. All of these paths *suck*, and in a big way. Breaking their contract with Broadcom is illegal. Committing large-scale copyright violation of Linux is illegal. Withdrawing their product... well, it ain't illegal, but it most likely means a whole bunch of people losing their jobs, and is a good PR case for folks to use who are trying to scare customers away from the embedded Linux houses (one of which I used to work for).
My hope is that they'll be able to work out an agreement with Broadcom under which they can distribute the relevant bits; that's probably the closest thing available to an everybody-wins solution.
Hey, I'm not saying it's justified, I'm just saying it's easy to go screw oneself and end up in a situation with no easy out.
Eh? I'm not sure I follow you.
The reason they're not releasing the drivers is (quite possibly) that they can't, due to NDAs and such with Broadcom -- not that they're trying to minimize their competition's barrier to entry.
If this is the case, however, then they're between a rock and a hard place -- since they've got this code statically linked, they don't qualify for Linus's modules-aren't-derivative-works exemption.
Further, this is quite possibly something that came up later in the development cycle than when the which-OS-do-we-use decision went through; it's easy to just be too heavily committed to make a switch partway through. (And then, there are other factors -- maybe they had folks on staff already familiar with using Linux for embedded work but who would need to retrain to be familiar with kernel hacking the BSDs, or perhaps they already had a contract with a Linux vendor to provide them with an embedded development environment, support, and so forth).
What I'm saying is that "oh, well then, we'll just use BSD" isn't always such an easy decision to make.
What's the big deal anyway? The thing uses proprietary hardware, so in order to reproduce it, you'd also have to have the masks to make the chips anyways
Err, well, no.
It actually uses, for instance, a set of chips manufactured by Broadcom. Anyone else building an embedded system and looking to use those chips -- or writing drivers for PC hardware based on those chips -- would have a great deal of use for these drivers.
Just as a comment, the licensing costs for WinCE aren't that huge at all -- maybe $5 per unit if my memory serves?
OTOH, last I was aware of it, its networking stack's performance was downright *abysmal*.
The difference is that when an airplane runs out of gas it tends to crash from a much higher altitude, a person falling off a Segway is getting off much easier then a pilot with a dry tank.
Airplanes can glide. A small plane can use a flat, straight highway as a landing strip in a pinch. An airplane pilot at a good height without any running motors has (compared to someone on a suddenly-toppling Segway) plenty of time to figure out how to recover from their situation.
I'll grant, however, that given the choice, I'd probably rather be on the Segway.
But I doubt that the whole desktop system based on MIPS would be cheaper than performance-equal x86 ones.
Okay, I thought I tried to make this point earlier... but maybe not.
For a low-end workstation, who the hell cares about "performance-equal" any more?
Low-end workstations all perform more than well enough to browse the web, read email, run a word processor or run remote apps off a server. Additional performance no longer really buys additional relevant functionality in the low-end workstation market... which is why things like silent running become more important than speed.
I'll grant that a MIPS-based line of low-end workstations would need a substantial production quantity to hit the right price point -- but *given* that (and presuming one is building ones' own components), the additional functionality (ie. very low power consumption/heat usage) is potentially enough to make them competitive even if they aren't performance-equal.
I also recall thinking that a large dog that's very close when you're born might very well have a greater effect on your life than Saturn
What you sayin' bout my momma?!
The *original* subject which spawned this thread was Intel being scared.
That said, part of my point was potential for bleedover. If low-end workstations become, as a rule, Linux based (and thus have less software requirements tying them to a given architecture), it's all the easier for them to go over to MIPS -- at which point the manufacturers can do customer-friendly things like... say... leave out the fans, and have an almost silent-running system (particularly in the case of diskless systems, where the "almost" can be discarded, or some of Seagate's hard drives designed with low noise levels in mind).
That's if you're buying for high performance rather than, say, battery life or heat output.
In embedded space, MIPS and SH *smoke* Intel on those counts. It'd be rather a bad thing if they moved heavily into other markets as well, no?
One of the useful things about C is that it can be viewed as an abstract version of assembly language -- it's somewhere between "easy" and "trivial" to look at just about any chunk of code and *know* how an unoptimized compiler would implement it. Correspondingly, C encourages a programmer to think in terms not of abstractions, but in terms of what precicely the machine itself is actually doing when running their code. If C had been written with some of the safety features of higher-level languages in mind, I suspect that some varieties of low-level coding -- writing drivers, for instance -- would be negatively impacted (whadaya mean I can't write to this arbitrary pointer value?)... and as long as you *can* write to an arbitrary memory location, your program can still do Bad Things if subverted.
Higher-level languages -- and Ada is among them -- lose this what's-going-on-under-the-hood focus, and tend more towards *forcing* the user to work in terms of abstractions rather than dropping down into high-level-assembly mode when appropriate. I'll agree that thinking in abstractions is a Good Thing in a great many cases -- but writing low-level code just ain't one of them, and that's exactly what C is good for.
Having your compiler be able to choose between "safe and unsafe string types", for instance, means that you've got a high-enough level language that the compiler actually understands what a string is. This (a "string") is an abstraction. C programs don't deal with abstractions on that level -- they deal with null-terminated arrays of 8-bit values, not with "strings". The compiler doesn't know that array-of-8-bit-values $FOO is a "string" and can have its underlying representation changed at will, but that array-of-8-bit-values $BAR happens to be in a memory location which corresponds to the internal memory of some PCI device on the system and must be represented *exactly* as the programmer indicates. Use an abstract language if you want a compiler that understands such things... C is not that language, and it's *intentionally* not that language, because having a sufficiently low-level language is Useful And Good. (Besides, having the compiler choose between multiple internal representations for the same code would be evil, because it means the same code would have different calling conventions based on compiler flags).
It's been years (about 6 of them, I think) since I've written any Pascal, and my memory span is measured in months if not weeks... so I'm going to not touch that thing, except to mention that I'm quite sure every major Pascal compiler vendor had extensions to implement pointer arithmetic on account of the language being difficult to express some algorithms in without it.
And by the way, if this is a whole big long collection of unfocused rambling, I'm *really* short on sleep right now, and am just about to go hit the sack rather than continuing to blather on about things while my brain's too tired to work.
Tsk, tsk. Repetition as a means of driving a point home is an established and well-respected tool of debate. The one-line summary doesn't carry the *weight* of the expanded version -- which is precicely the effect I was going for.
Cleaner, more readable code is probably loaded with bugs or lacking in features because it hasn't been around long enough to have all the disgusting hacks and patches applied to it that are required for extended use in the real world.
What this means is that you haven't spent time in the real world on a programming team with an architect who believes in constant, aggressive refactoring -- and is willing to bully the suits (and the coders, and everyone else) as much as necessary to be sure it gets done.
I'm on such a team. There're ugly hacks in our code, sure -- but they don't last more than a month or so before getting refactored out.
Consider that an object lesson in why denormalization is sometimes a Good Thing.
A good replacement for C, eh? How 'bout C? Or, say, C?
Honestly, though: For low-level programming, there *is* no good replacement for C, for a simple reason: the same power that makes it dangerous is also the power that makes it useful. For high-level programming, there are lots of good replacements -- and you just mentioned, and wrote off, two of the best of them.
Java is getting better (witness the presence of the NIO API in 1.4), and I've got strong hopes for C# and its kin -- but part of what makes C# so useful is its simple API for access to C libraries, something that Java makes much harder. That said, for almost all of the high-level programming I do, I use Python (except at work, where I don't always get to pick; in the cases where I don't have the choice, I write Java).
Sure, Python and Java aren't suitable for low-level work -- but that's what C is good for. And since calling from Python down to C is simple, writing optimized versions of performance-sensitive routines is easy, in the rare event that it actually needs to be done (which has, in my five or so years of writing Python, happened all of once, when I needed some efficient drawing routines which were most readily available from a C library without preexisting python bindings).
Compiling Java to native code with GCJ also decreases the startup-time and runtime performance penalty without sacrificing type-safety -- and works for applications using an increasingly large subset of the available APIs.
Scheme is another language that many folks are too quick to write off. Not only does the language have the expected type-safety goodness -- but compiled scheme can be *very* fast. (On the down side, the lack of a useful standard runtime library is very disappointing).
So, yes, for high-level stuff, there are lots of alternatives... but what are you going to write your Python interpreter or low-level libraries in? For some jobs, there's still no good replacement for C. (Further, I'm not by any means convinced that low-level work *should* be done in an OO language... but that's a different conversation).
looks don't mean jack or shit.
In code, looks mean quite a lot.
Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.
Corporations exist to do what their shareholders want them to, and to fulfill the purpose specified in their articles of incorporation. Usually what the shareholders want is to make money... but then, we don't know who Eolas's shareholders are, much less what they want. Consequently, they could well be out for vengeance.
I could see these arguments applied to W.R. Grace and PG&E, but SCO c'mon.
Eh?
SCO is trying to discredit the product of thousands of man-years of hard work, many of which were put in voluntarily as nothing more than a labor of love. They're attempting to prevent me from using code I helped write in my own workplace without paying them an unreasonable fee. Because I'm one of those open source developers whose ethics, practices and motivations they're calling into practice, they're attacking me personally -- and thousands and thousands more like me besides -- without evidence, without just cause, without any motivation besides profit.
Granted, I've not been following the news lately (and haven't been in California for over a year now), but I'm not aware of anything PG&E has done that's even nearly as severe.
That you don't have the cojones to swallow your pride and tough it out for them. Sure pride and ideals have their place, but so does humility and sacrifice.
Funny, I thought suborning one's ideals to keep receiving that paycheck was the choice indicative of the lack of cojones.
Humility and sacrifile are by all means good qualities, I'll grant -- but something's very wrong if they're being used as an excuse to participate in something which is morally bankrupt.
The "I'm just a grunt" defense has been discredited for war crimes... why, again, does it apply here?
I'm not saying Damage doesn't have the right to question the integrity of any former SCO employees, just that they shouldn't be prejudging them when there may be extenuating circumstances.
Can you really argue with that last statement?
No, I can't. Someone else here posted a link to the resume of one of SCO's lead open source developers, who mentioned that he may be soon looking for a new job doing open source work. Looking over it, I was almost tempted to send him an email asking if he'd consider applying with my last employer -- MontaVista Software -- as he looks like a generaly good fellow and would probably fit in well there.
I'm not going to say there's anything wrong about Damage's stand, though -- besides that it unnecessarily prevents them from potentially being able to hire what few talented and yet non-morally-bankrupt employees SCO has left. That's their loss, though, and if they think that they'd rather make a political point (and not need to sift through the resumes from folks at SCO *without* said extenuating circumstances), such is their choice to make.
(Why "what few" talented yet non-morally-bankrupt employees? Because the most talented folks are the ones who have the easiest time finding new work, even in a down market, and so who have the least disincentive to leave when the company's actions offend them. Also, typically, a good chunk of such folks are idealistically motivated; many of my better coworkers at MontaVista were there not only because they liked the paychecks but because they wanted to help improve open source software).
Having to pay two car payments (rather than buying a $500 used commute vehicle or two) or substantial consumer debt is indicative of bad choices; and in a two-parent household, needing childcare implies that both parents are working -- so if only *one* of them gets their pay cut to $25k/yr, that's not so bad (and if it's via complete loss of income for one of those two that the income is cut to $25K/yr, childcare is no longer needed as the nonworking parent can provide childcare {him,her}self). Likewise, student loans are avoidable -- I paid my own way through college without a single loan, as did my father. One student I know just made $15K over the last summer selling books door-to-door -- more than enough to finance a year of studenthood (my expenses were $9k/yr, and could have been less had I been more diciplined with regards to my spending).
Having a family changes things, that I'll grant -- but nonetheless, being unable to have two cars that cost more than one has in available cash or being unable to afford the goodies that result in "consumer debt" or needing to have ones' kids pay their own way through school is by no means an impossible, life-shattering level of hardship.
My income, excluding hitherto worthless stock options, has never been more than $23K/yr; despite that, I've been able not only to pay my own way but to make substantial fiscal contributions to the wellbeing of those close to me (including more than one family with children). Living cheaply takes some dicipline, no doubt -- but it's entirely possible for those willing to make the appropriate compromises. As for those who aren't so willing -- the situations they put themselves in are thus their own fault, and I see little cause for sympathy.
Being unwilling to move around the country as needed is another expensive lifestyle choice. If someone chooses to live somewhere with a cost of living they're unable to support, I hardly see that as a reason for sympathy either. (And yes, I *have* moved halfway across the country myself, with cost-of-living differences among prime motivating factors).
Let me direct you to the opening section of A Nation Of Cowards for an alternate perspective on the value of human life.
Some of my friends live out in the country. When folks come over, they leave their keys on their dashboards and their car doors unlocked, so that if anyone needs to move their car they can do so. Vehicle theft is unheard of -- because it's taken as given that out there, half an hour away from any police force, everyone is armed. It goes without saying that they leave their doors unlocked, as well; home invasion is another thing that simply doesn't happen there.
The level of comfort from living in a society with that level of trust -- to be able to leave one's property out in the open, unprotected -- may be something you don't know; perhaps you live in big metropolitan area somewhere. In any event, I'm more than happy to pay the price of a few foolhardy criminals -- "individuals" lacking respect for their fellow members of society -- being shot while stealing a DVD player.
And by the way, one of my best friends once spent several years in jail for a crime which, had he committed it in Texas, the person he had committed it against could have shot him for[*]. He's a good person, and I value his life -- but that makes me no less convinced that it would still have been morally just for the person whose property rights he violated to have defended said rights by force.
[*] "for", in this case, meaning to stop him from committing said crime or escaping from it; presuming that the person against whom the crime was committed reasonably believed he could not safely stop it using lesser means -- which, being that my friend is/was a martial artist, is likely.