I fail to see how anything these scapegoats said would change the survival rate of the earthquake. With or without accurate warnings, people would likely still have died just the same--since they cannot predict the exact moment an earthquake will strike, it's reasonable to assume some people would be caught in the wrong place at the wrong time--and fatally so, regardless.
How much different did they expect the people to behave had "adequate" warning been provided? Did they expect everyone to evacuate? Sounds just like a damned-if-you-do, damned-if-you-don't scenario for these guys.
Ultimately, the *earthquake* is to blame for the fatalities--not the (in)accuracy of the geologist's predictions or warnings. They should not be held liable for deaths by natural causes. This is truly ludicrous. I hope they win on appeal.
A driver may well choose property damage over bodily harm--eg crash into another vehicle rather than hit a pedestrian that radar may not even detect. I cannot believe this will sell.
We know from experience that hidden files won't stay hidden for long. A little coersion and it confesses everything--all in hopes that it won't get reformatted.
You may like sipecs. They even have a pre-configured distro cd if you want to get up and running quickly--just install it, plug in your voip phones, and it will discover and configure them.
My path was: Caldera OpenLinux 1.1 - 1 year Mandrake - 1 year RedHat - 2 years LFS - 2 years Gentoo - 8 years and counting
With some HP-UX, IRIX, and debian sprinkled in on some non-x86 arches.
If your end goal is to be a master of Linux/unix in general:
I highly recommend doing LFS at least once. It strips away all the helpers (which sometimes complicate things), and forces you to know for each package how it natively behaves, their own config files, locations, etc. You learn what happens from boot on up to the login prompt. You learn what all the pieces are, what they do, etc.
I also highly recommend trying Gentoo at least once--at least until you learn how portage keywords and package use flags work so you can honestly compare to rpm/apt in other distros. Gentoo is a happy compromise--a step back from LFS in that it normalizes most of the configuration locations and services control, and adds full package management, but all while still allowing you to take finer-grained control selectively as you want/need. (Personally, I prefer gentoo's way of configuring services to the other main distros--it feels more flexible and less "in-my-way"ish, especially for disk layout and network configuration.)
From there, you can learn any distro you want/need. (But I'd guess that most people that give gentoo an honest try wind up sticking with it since it has fewer cons and more pros than most of the other canned distros. BTW, it does support binary packages--many do not know this.)
If your end goal is not administrative prowess, but simply to use it as a desktop:
You probably should stick to a well-supported end-user-focused distro such as ubuntu, fedora/redhat, suse. You may not get bleeding edge, but you won't bleed--and many help topics on the web cater to these main distros. IMO, for such an end goal it really doesn't matter which distro you use first--they will all have some shortcoming that will require some googling to figure out--no distro of any OS has all the kinks worked out.
A study by researchers from New York University, published today in the Journal of the American Medical Association, looked at a sample of nearly 3,000 children and teens across the country and found a 'significant' link between the amount of BPA in their urine and the prevalence of obesity.
Children and teens != mice. The above statement sure sounds like a "conclusion" of sorts...
People who chew gum are more likely to contract throat and lung cancer. Correlated? Yes. Cause: people who *smoke* are more likely to chew gum to freshen their breath afterwards.
BPA--in containers of crappy processed foods and beverages. Grain-laced soda -> fat.
As "smart" as some of these researchers seem to be, they often come up with the *dumbest* conclusions.
It's called "good documentation". I recall reading that the F-22 production line was videotaped from start to finish, with workers explaining their jobs and going through the motions. This was fleshed out with interviews in order to capture institutional knowledge that usually disappears when production lines are shut down and workers leave.
Ceramics enjoyed an extended period as a top tier technology and then continued on as a legacy, but still critical-for-civilization technology. Once we reinvent their old technology, there's no reason for it to ever be lost again.
Sure, that can go a long ways, but I still think there's room for stuff to get lost in translation. "tricks of the trade" that really need to be shown/taught/critiqued in person. It's *really* hard for most humans to learn fine motor skills out of a book or video--having personal instruction for feedback/correction is paramount. There's a reason some skills were historically learned via apprenticeship for years before reaching "journeyman" status--there really can be a lot to it, and you can't easily capture it let alone reproduce it just from documentation.
There's lots of stories of cases where someone needs to use some older technology and despite understanding it (they have the knowledge) they still have to hunt down an old-timer to show them how to use it (skill).
We can capture the knowledge--but it's the skills I think we most risk losing.
NASA had to resurrect fabrication techniques from the days of the gold rush gold mines to build some of their parts large enough for the rockets that went to the moon.
It seems that there's a lot of knowledge and skills that are getting lost as we "progress". Sure, some of it is useless since we truly have replaced things with better stuff, eg linotype. But then again, there are some technologies and skills that are dying off that would be good to capture somehow, such as how to build and work a foundary. I'm not sure of a good way to capture *skill*--it's usually passed on person-to-person.
If you don't want people to have a copy your photo, then don't share it in the first place. It's that simple. Once you publish, it's out, simple as that.
Why don't people understand these simple concepts?
No different than "Hey, Robert told me a secret--it's supposed to be just for me, so don't tell anyone else!..."
executive summary: here's another paedophile apologist
1) "I may not agree with you but will defend to the death your right to say it." 2) s/say/think/ 3) evaluate: Now, how does this make me a *paedophile apologist*? Replace the topic at hand with any other less-than-socially-acceptable topic, just because I defend a person's right to think what they want about it, and *you* don't like the topic, that makes me an apologist *for those aligned with topic itself*? There's a big difference.
As per TFA, defining "child porn" and "creating it" needs to be done extremely carefully. I wouldn't say all should be illegal to produce--depends on what occurs, who's involved, who/how/when it was filmed, the ages, the level of consent, etc. I think a good rule of thumb should be, if a *physical crime* is commited *for the purpose of making a film*, then the creation of the film is also a crime--it's accessory at the very least. If someone randomly filmed a child being raped, only the rape was the crime--not the filming. While on the outset this might appear to open a loophole for pornographers by simply making all films look like they were taken by an innocent bystander, it ought to be evident if one organization has a pattern of this and are seeking to profit from it... Perhaps as the author suggests, simply changing the age to 13, which is much closer to the average pre/post pubescence transition would mitigate most of the ambiguities.
Thoughts should *never* be a crime. Child porn that already exists is just bits--the crime of creating it has already been committed.
Here's what I see with having possession of child porn illegal: 1) some people will have a fettish/fantasy of sex with minors--you *cannot* change that in them and hoping to do so is futile--and like you said, it's not a crime to think it. 2) I'd much rather those people satisfy their urges in private with porn, leaving actual children safe 3) if the porn is eliminated, some of those people may become frustrated to the point of satisfying their urges by harming children--this is obviously an undesireable outcome 4) some people that harm children will do so regardless of porn--so regulating the porn does *nothing* to styme their actions--they simply need to be dealt with for the physical offenses they do commit
Here's my proposal: - creating child porn remains illegal--go after the producers and sources of the content since they are committing physical offenses - possession of existing child porn is legalized--the damage has already been done, stop chasing the consumers of it--it's futile anyways - stop making a big deal out of the consumers--so long as they keep it to themselves it shouldn't be anybody's business - don't worrry about the existing content--the damage is done, removing it may incur more damage as per (3) above - only *producing* it should be illegal, sharing it should not be--it's just bits: a) I'd rather consumers be able to get it than not, b) this would eliminate all the crap that can happen when someone/thing (virus/malware/person/whatever) puts it on someone's system and they get in trouble for having or having transferred the bits whether knowingly or not
One other issue that bosses and clients seem to be unwilling to accept sometimes, is an "I don't know" estimate. No matter how similar problem A may appear to problem B, quite often the details may be such that the developer cannot really know how long it will take--it's different enough that it's essentially a new problem to solve. Often times, solving a problem is exactly like finding your lost car keys--you just don't know how long it will take you. These scenarios do occur, and they frustrate all parties--the boss/client demanding an estimate, and the developer who is struggling to not be forced to give a WAG and later be called out on being wrong. No matter in which direction he's wrong, both look bad--if it takes far less time, then he is suspected of padding other things, and if he takes much longer, he looks like a bad estimator or worse--a poor performer.
When bidding a project, I recommend you split it into two: 1) scope and prototype - enumerate exactly what the features will be - create a mock-up of how it will look and function so the client can visualize what the scope includes 2) the actual implementation of (1)
Clients never know exactly what they want. Even after seeing it and using it, often they discover it's not quite what they needed. This causes feature creep--which is the bane of all software projects. You have the conundrum: a) you charge a flat fee for the project, meaning the client gets infinite features for a fixed rate and you lose b) you charge an hourly fee, meaning the client feels screwed the more they realize they forgot stuff or didn't originally understand it well enough to tell you "right" the first time
I've found that this approach allows you to help mitigate this. Do (1) at possibly a lower rate than (2), and even do (2) at a fixed fee if you are confident in your estimation of the work involved, but only after (1) is complete and they sign off on everything in the scope and how you've demoed it to look and feel.
Farm-raised, grain-fed pork is by definition not healthy. Grain-feeding pigs is nowhere close to their natural diet. They are omnivores--they naturally eat fruits, some veggies, and other *animals*, much like humans. *Grain* is neither fruit nor vegetable, and is nowhere in their natural diet. (It isn't in our natural diet either, but that's another topic.) Interesting factoid #1: wild pork is *red* meat--not white. Interesting factoid #2: wild boar and domestic pigs are the *same* species. When a pig escapes, it only takes about a year for it to grow its fur back and behave as if it had always been ferrel. (Which means that domesticated pigs are under distress--so much so that they shed their hair!)
- huge behemoth office suite that interoperates w/the defacto standard? libre office. check. - popular, familiar browser? firefox, check. - cross platform gui toolkits? QT, others, check. - *stable* API? I dunno what people are complaining about. The standard c library and POSIX OS API have been stable for ages. check.
I think the bigger problem is *too many* apps included by default--no defacto standard across distros. (But this is what *choice* brings us.)
Users cannot sit down at any linux machine and expect the same experience. They can't expect to always find: - IE - office - outlook - msn - notepad - ms paint - solitaire (seriously--it's one of the most commonly used apps in the world)
in the same place and working the same way. There's no IE browser, but there could be konqueror, firefox, chrome, opera. There's no MS Office, but they might find kofifce, libre office, abiword, etc. There's a dozen possible IM clients. There's a dozen possible text editors. There's no IE GUI file explorer--but there could be konqueror, nautilus, dolphin, or other There's a half dozen paint programs that might be there. There's no outlook, but there could be kmail, thunderbird, or a few others.
And that's just the common apps. They want to install something else, they immediately find: - there is *no* consistency between distros - the app they want is probably not ported to Linux in the first place (guess that answers my question--"what apps?"--well we just don't know, but can't expect every dev to make every app cross platform for our favorite platform)
This doesn't even consider what developers have to do to target different distros. RPM, dpk. portage, etc.
Linux is certainly for the most part *source* compatible with a stable c library and POSIX API. But any number of combinations of library versions could be found on a target system--which is why any time I've ever got a commercial app, it usually came w/static linkage so that it would just work.
I see no difference between linux distros and the developers behind them--they are all cats and you cannot herd them. It's a problem, that by the nature of it's participants cannot be solved. Desktop Linux will largely remain for developers, by developers--or for people closely related to developers/admins that will install and maintain it for them, or for tinkerers. But not average-day Joe and Susie--it's not consistent enough.
Users no longer anticipate sitting down to a computer system and having to learn it/figure it out. They expect uniformity to the commodity systems in existence. *Unless*, they *know* it's some new system and are expecting to figure it out--but in that case, they *expect* it to be the same everywhere they go. Thus "Linux" is not the best name to use. Really, you'd have to distinguish by saying the distro name. Eg, "Android"--everyone knows what to expect--there are small variations, but they all work essentially the same--no worse than differences in version of Windows.
Thus, "Linux on the Desktop" is a misnomer. It really should be "Ubuntu on the desktop" or "Suse on the desktop" or "Debian on the desktop". So really, it's two problems: 1) which distro is defacto standard (there will never be one--intractable problem) 2) for said distro, what keeps it from becoming a good desktop alternative to Windows and Mac? (see problem #1, and issues above)
How does this intersect with the principal of jury nullification? Does the Rule 50 motion mean the judge can trump that? It's been my understanding that jury nullification is the last check and balance we the people have against unwanted legislation. Not true if the judge can throw out the jury's verdict anyways.
Calling yourself a "microsoft partner" is just fluff. I know lots of tiny companies that plaster that on their website to try and look bigger than they really are--when all it really means is they have an MSDN subscription, use their os, use ms office, and use visual studio...
I worked at a small company that shouted "MS Partner" in the same way, but we went so far as to produce and maintain a custom linux distro for our linux-based product.
While that may be true for small libs, QT has such a massive usage base I can't imagine a team won't evolve to pick it up and continue it. I've no doubt some of the employees, some devs from KDE, some from other large projects may join in to carry its torch.
The KDE devs can't let it die--because their project depends on it--so they have a vested interest to maintain it even if it turns out no one else cares (which by itself is not likely).
Furthermore, it's for sale--not hovering/dev/null. Some other company may purchase it with just as much or more interest in seeing it move forward.
Well, why not simply decouple the two operations--they already did so for instantiation: __new__() and __init__(), why not separate the converse with __deinit__() and __del__()? Then when you call "del foo" in code, you are invoking __deinit__() destruction, freeing resources, etc, but leaving the GC free to call __del__() when or if it sees fit. That's the real pattern RAII wants anyways--tying resources to the semantically-meaningful life of the object, not the life of the object in memory (since that is non-deterministic/varies by GC algorithm).
As for switch/case, either add that, or goto. There *are* use cases where it makes coding cleaner/easier to read--which is one of the underlying points to python, isn't it?
And a 3rd item: if you're not gonna have goto, then at least allow break to accept a parameter to know how many levels to break out of... having to manage and test extra flags just to exit out of multiple-nested blocks at once is much less readable.
Slashdot Mirror
I fail to see how anything these scapegoats said would change the survival rate of the earthquake. With or without accurate warnings, people would likely still have died just the same--since they cannot predict the exact moment an earthquake will strike, it's reasonable to assume some people would be caught in the wrong place at the wrong time--and fatally so, regardless.
How much different did they expect the people to behave had "adequate" warning been provided? Did they expect everyone to evacuate? Sounds just like a damned-if-you-do, damned-if-you-don't scenario for these guys.
Ultimately, the *earthquake* is to blame for the fatalities--not the (in)accuracy of the geologist's predictions or warnings.
They should not be held liable for deaths by natural causes. This is truly ludicrous. I hope they win on appeal.
A driver may well choose property damage over bodily harm--eg crash into another vehicle rather than hit a pedestrian that radar may not even detect.
I cannot believe this will sell.
We know from experience that hidden files won't stay hidden for long. A little coersion and it confesses everything--all in hopes that it won't get reformatted.
You may like sipecs. They even have a pre-configured distro cd if you want to get up and running quickly--just install it, plug in your voip phones, and it will discover and configure them.
My path was:
Caldera OpenLinux 1.1 - 1 year
Mandrake - 1 year
RedHat - 2 years
LFS - 2 years
Gentoo - 8 years and counting
With some HP-UX, IRIX, and debian sprinkled in on some non-x86 arches.
If your end goal is to be a master of Linux/unix in general:
I highly recommend doing LFS at least once. It strips away all the helpers (which sometimes complicate things), and forces you to know for each package how it natively behaves, their own config files, locations, etc. You learn what happens from boot on up to the login prompt. You learn what all the pieces are, what they do, etc.
I also highly recommend trying Gentoo at least once--at least until you learn how portage keywords and package use flags work so you can honestly compare to rpm/apt in other distros. Gentoo is a happy compromise--a step back from LFS in that it normalizes most of the configuration locations and services control, and adds full package management, but all while still allowing you to take finer-grained control selectively as you want/need. (Personally, I prefer gentoo's way of configuring services to the other main distros--it feels more flexible and less "in-my-way"ish, especially for disk layout and network configuration.)
From there, you can learn any distro you want/need. (But I'd guess that most people that give gentoo an honest try wind up sticking with it since it has fewer cons and more pros than most of the other canned distros. BTW, it does support binary packages--many do not know this.)
If your end goal is not administrative prowess, but simply to use it as a desktop:
You probably should stick to a well-supported end-user-focused distro such as ubuntu, fedora/redhat, suse. You may not get bleeding edge, but you won't bleed--and many help topics on the web cater to these main distros. IMO, for such an end goal it really doesn't matter which distro you use first--they will all have some shortcoming that will require some googling to figure out--no distro of any OS has all the kinks worked out.
From the post:
A study by researchers from New York University, published today in the Journal of the American Medical Association, looked at a sample of nearly 3,000 children and teens across the country and found a 'significant' link between the amount of BPA in their urine and the prevalence of obesity.
Children and teens != mice.
The above statement sure sounds like a "conclusion" of sorts...
People who chew gum are more likely to contract throat and lung cancer.
Correlated? Yes.
Cause: people who *smoke* are more likely to chew gum to freshen their breath afterwards.
BPA--in containers of crappy processed foods and beverages.
Grain-laced soda -> fat.
As "smart" as some of these researchers seem to be, they often come up with the *dumbest* conclusions.
It's called "good documentation".
I recall reading that the F-22 production line was videotaped from start to finish, with workers explaining their jobs and going through the motions.
This was fleshed out with interviews in order to capture institutional knowledge that usually disappears when production lines are shut down and workers leave.
Ceramics enjoyed an extended period as a top tier technology and then continued on as a legacy, but still critical-for-civilization technology.
Once we reinvent their old technology, there's no reason for it to ever be lost again.
Sure, that can go a long ways, but I still think there's room for stuff to get lost in translation. "tricks of the trade" that really need to be shown/taught/critiqued in person. It's *really* hard for most humans to learn fine motor skills out of a book or video--having personal instruction for feedback/correction is paramount. There's a reason some skills were historically learned via apprenticeship for years before reaching "journeyman" status--there really can be a lot to it, and you can't easily capture it let alone reproduce it just from documentation.
There's lots of stories of cases where someone needs to use some older technology and despite understanding it (they have the knowledge) they still have to hunt down an old-timer to show them how to use it (skill).
We can capture the knowledge--but it's the skills I think we most risk losing.
NASA had to resurrect fabrication techniques from the days of the gold rush gold mines to build some of their parts large enough for the rockets that went to the moon.
It seems that there's a lot of knowledge and skills that are getting lost as we "progress". Sure, some of it is useless since we truly have replaced things with better stuff, eg linotype. But then again, there are some technologies and skills that are dying off that would be good to capture somehow, such as how to build and work a foundary. I'm not sure of a good way to capture *skill*--it's usually passed on person-to-person.
If you don't want people to have a copy your photo, then don't share it in the first place. It's that simple. Once you publish, it's out, simple as that.
Why don't people understand these simple concepts?
No different than "Hey, Robert told me a secret--it's supposed to be just for me, so don't tell anyone else!..."
executive summary: here's another paedophile apologist
1) "I may not agree with you but will defend to the death your right to say it."
2) s/say/think/
3) evaluate:
Now, how does this make me a *paedophile apologist*?
Replace the topic at hand with any other less-than-socially-acceptable topic, just because I defend a person's right to think what they want about it, and *you* don't like the topic, that makes me an apologist *for those aligned with topic itself*?
There's a big difference.
As per TFA, defining "child porn" and "creating it" needs to be done extremely carefully.
I wouldn't say all should be illegal to produce--depends on what occurs, who's involved, who/how/when it was filmed, the ages, the level of consent, etc.
I think a good rule of thumb should be, if a *physical crime* is commited *for the purpose of making a film*, then the creation of the film is also a crime--it's accessory at the very least. If someone randomly filmed a child being raped, only the rape was the crime--not the filming.
While on the outset this might appear to open a loophole for pornographers by simply making all films look like they were taken by an innocent bystander, it ought to be evident if one organization has a pattern of this and are seeking to profit from it...
Perhaps as the author suggests, simply changing the age to 13, which is much closer to the average pre/post pubescence transition would mitigate most of the ambiguities.
I agree with some of your arguments.
Thoughts should *never* be a crime.
Child porn that already exists is just bits--the crime of creating it has already been committed.
Here's what I see with having possession of child porn illegal:
1) some people will have a fettish/fantasy of sex with minors--you *cannot* change that in them and hoping to do so is futile--and like you said, it's not a crime to think it.
2) I'd much rather those people satisfy their urges in private with porn, leaving actual children safe
3) if the porn is eliminated, some of those people may become frustrated to the point of satisfying their urges by harming children--this is obviously an undesireable outcome
4) some people that harm children will do so regardless of porn--so regulating the porn does *nothing* to styme their actions--they simply need to be dealt with for the physical offenses they do commit
Here's my proposal:
- creating child porn remains illegal--go after the producers and sources of the content since they are committing physical offenses
- possession of existing child porn is legalized--the damage has already been done, stop chasing the consumers of it--it's futile anyways
- stop making a big deal out of the consumers--so long as they keep it to themselves it shouldn't be anybody's business
- don't worrry about the existing content--the damage is done, removing it may incur more damage as per (3) above
- only *producing* it should be illegal, sharing it should not be--it's just bits: a) I'd rather consumers be able to get it than not, b) this would eliminate all the crap that can happen when someone/thing (virus/malware/person/whatever) puts it on someone's system and they get in trouble for having or having transferred the bits whether knowingly or not
I agree with you completely.
One other issue that bosses and clients seem to be unwilling to accept sometimes, is an "I don't know" estimate.
No matter how similar problem A may appear to problem B, quite often the details may be such that the developer cannot really know how long it will take--it's different enough that it's essentially a new problem to solve. Often times, solving a problem is exactly like finding your lost car keys--you just don't know how long it will take you. These scenarios do occur, and they frustrate all parties--the boss/client demanding an estimate, and the developer who is struggling to not be forced to give a WAG and later be called out on being wrong. No matter in which direction he's wrong, both look bad--if it takes far less time, then he is suspected of padding other things, and if he takes much longer, he looks like a bad estimator or worse--a poor performer.
Obviously, you can lather, rinse, and repeat this as they discover new things that they want--but doing this cycle keeps everything fair.
When bidding a project, I recommend you split it into two:
1) scope and prototype
- enumerate exactly what the features will be
- create a mock-up of how it will look and function so the client can visualize what the scope includes
2) the actual implementation of (1)
Clients never know exactly what they want. Even after seeing it and using it, often they discover it's not quite what they needed. This causes feature creep--which is the bane of all software projects. You have the conundrum:
a) you charge a flat fee for the project, meaning the client gets infinite features for a fixed rate and you lose
b) you charge an hourly fee, meaning the client feels screwed the more they realize they forgot stuff or didn't originally understand it well enough to tell you "right" the first time
I've found that this approach allows you to help mitigate this. Do (1) at possibly a lower rate than (2), and even do (2) at a fixed fee if you are confident in your estimation of the work involved, but only after (1) is complete and they sign off on everything in the scope and how you've demoed it to look and feel.
Farm-raised, grain-fed pork is by definition not healthy.
Grain-feeding pigs is nowhere close to their natural diet. They are omnivores--they naturally eat fruits, some veggies, and other *animals*, much like humans. *Grain* is neither fruit nor vegetable, and is nowhere in their natural diet. (It isn't in our natural diet either, but that's another topic.)
Interesting factoid #1: wild pork is *red* meat--not white.
Interesting factoid #2: wild boar and domestic pigs are the *same* species. When a pig escapes, it only takes about a year for it to grow its fur back and behave as if it had always been ferrel. (Which means that domesticated pigs are under distress--so much so that they shed their hair!)
I agree. What additional apps are lacking?
- huge behemoth office suite that interoperates w/the defacto standard? libre office. check.
- popular, familiar browser? firefox, check.
- cross platform gui toolkits? QT, others, check.
- *stable* API? I dunno what people are complaining about. The standard c library and POSIX OS API have been stable for ages. check.
I think the bigger problem is *too many* apps included by default--no defacto standard across distros. (But this is what *choice* brings us.)
Users cannot sit down at any linux machine and expect the same experience. They can't expect to always find:
- IE
- office
- outlook
- msn
- notepad
- ms paint
- solitaire (seriously--it's one of the most commonly used apps in the world)
in the same place and working the same way.
There's no IE browser, but there could be konqueror, firefox, chrome, opera.
There's no MS Office, but they might find kofifce, libre office, abiword, etc.
There's a dozen possible IM clients.
There's a dozen possible text editors.
There's no IE GUI file explorer--but there could be konqueror, nautilus, dolphin, or other
There's a half dozen paint programs that might be there.
There's no outlook, but there could be kmail, thunderbird, or a few others.
And that's just the common apps.
They want to install something else, they immediately find:
- there is *no* consistency between distros
- the app they want is probably not ported to Linux in the first place (guess that answers my question--"what apps?"--well we just don't know, but can't expect every dev to make every app cross platform for our favorite platform)
This doesn't even consider what developers have to do to target different distros. RPM, dpk. portage, etc.
Linux is certainly for the most part *source* compatible with a stable c library and POSIX API. But any number of combinations of library versions could be found on a target system--which is why any time I've ever got a commercial app, it usually came w/static linkage so that it would just work.
I see no difference between linux distros and the developers behind them--they are all cats and you cannot herd them.
It's a problem, that by the nature of it's participants cannot be solved.
Desktop Linux will largely remain for developers, by developers--or for people closely related to developers/admins that will install and maintain it for them, or for tinkerers. But not average-day Joe and Susie--it's not consistent enough.
Users no longer anticipate sitting down to a computer system and having to learn it/figure it out.
They expect uniformity to the commodity systems in existence.
*Unless*, they *know* it's some new system and are expecting to figure it out--but in that case, they *expect* it to be the same everywhere they go.
Thus "Linux" is not the best name to use. Really, you'd have to distinguish by saying the distro name. Eg, "Android"--everyone knows what to expect--there are small variations, but they all work essentially the same--no worse than differences in version of Windows.
Thus, "Linux on the Desktop" is a misnomer. It really should be "Ubuntu on the desktop" or "Suse on the desktop" or "Debian on the desktop". So really, it's two problems:
1) which distro is defacto standard (there will never be one--intractable problem)
2) for said distro, what keeps it from becoming a good desktop alternative to Windows and Mac? (see problem #1, and issues above)
How does this intersect with the principal of jury nullification? Does the Rule 50 motion mean the judge can trump that? It's been my understanding that jury nullification is the last check and balance we the people have against unwanted legislation. Not true if the judge can throw out the jury's verdict anyways.
Sounds like it has a case of memoroids!
Calling yourself a "microsoft partner" is just fluff. I know lots of tiny companies that plaster that on their website to try and look bigger than they really are--when all it really means is they have an MSDN subscription, use their os, use ms office, and use visual studio...
I worked at a small company that shouted "MS Partner" in the same way, but we went so far as to produce and maintain a custom linux distro for our linux-based product.
While that may be true for small libs, QT has such a massive usage base I can't imagine a team won't evolve to pick it up and continue it. I've no doubt some of the employees, some devs from KDE, some from other large projects may join in to carry its torch.
The KDE devs can't let it die--because their project depends on it--so they have a vested interest to maintain it even if it turns out no one else cares (which by itself is not likely).
Furthermore, it's for sale--not hovering /dev/null. Some other company may purchase it with just as much or more interest in seeing it move forward.
QT can't die. It's dual-licensed. There will always be the open-sourced version available.
May the fork be with us.
Who actually uses a file manager??
bash FTW.
Or, for complicated renames, emacs dired.
Well, why not simply decouple the two operations--they already did so for instantiation: __new__() and __init__(), why not separate the converse with __deinit__() and __del__()?
Then when you call "del foo" in code, you are invoking __deinit__() destruction, freeing resources, etc, but leaving the GC free to call __del__() when or if it sees fit.
That's the real pattern RAII wants anyways--tying resources to the semantically-meaningful life of the object, not the life of the object in memory (since that is non-deterministic/varies by GC algorithm).
As for switch/case, either add that, or goto. There *are* use cases where it makes coding cleaner/easier to read--which is one of the underlying points to python, isn't it?
And a 3rd item: if you're not gonna have goto, then at least allow break to accept a parameter to know how many levels to break out of... having to manage and test extra flags just to exit out of multiple-nested blocks at once is much less readable.