Not sure if this is relevant to your situation, but I've found that GNU std::list sucks compared to almost any other data structure. Never bothered to check why, I now just try to avoid it. Sorry, but you happened to stumble upon the worst of the lot.
If you think you can beat std::vector... good luck. You won't, for any non-POD type.
I want a desktop. I want a desktop that acts just like the desktop that all other relevant desktop environments on all other relevant operating systems. You know, like the one KDE3 has.
Everyone says that about every piece of technology until they discover something better. Even if it's ultimately not successful, I find it commendable that the KDE devs are willing to try something new.
If I buy a Microsoft or Apple product, they have an obligation to fix my bugs, or they lose my money and get bad publicity.
No they don't. They have an obligation to weigh the cost of your bad publicity and lost business against the cost of fixing the bug, and then do whatever makes more sense for themselves. And the answer will most likely be "screw you" unless everyone else is having the same problem.
You, as an individual consumer of a piece of software from MS or Apple, don't have the power you think you do.
Yeah, they probably should have gone with "KDE-Core-4.0" and only bundled the necessary applications. But it still would have caught flak from people, since whatever word you use (Core, Libs, whatnot) will still be ignored by a vocal minority.
I think you're missing the point that 4.0 was stable for developers. For a desktop environment with a big hairy dependency chain and massive internal churn, providing a stable library release is a critical step to help application developers. The alpha/beta/rc terminology doesn't work so well when the ultimate goal is releasing 1/2 of the platform.
It would have been interesting if they had decided to call it "4.-1", though.
In open-source projects, whole numbers also generally suggest more aggressive churn, which means more bugs. I think it's pretty common for *.0 releases to have weird new bugs. KDE just pushed that to the next level by making sure some of those bugs were "application X does not exist yet".
Welcome to Linux on the desktop, where technical terminology and endless blame are the only responses you get to flaws in the product. Imagine telling your grandma to "just change the user agent." Linux on the desktop fails again.
What? It's not like this is some sort of failing of Linux. If a website is using User-Agent sniffing, and it rejects anything it doesn't think is MSIE, it's the fault of the website for not working, not the browser.
Your comment is akin to blaming Richard for being banned from accessing the "Todds Only" grocery store. It's his fault for not being Todd! Right?
"Higher signal-to-noise ratio across a broader range of the United States" just isn't quite as catchy a slogan.
I'm pretty sure it violates some truth-in-advertising laws as well. Hence the switch (by AT&T) to the cushy-feel-good "more bars in more places". Impossible to argue against a meaningless metric!
I think the point is that it'd be nice if these things worked in a linear and predictable fashion.
I think the point of the GP is that you're in the (high-maintenance) minority for demanding linear output from nonlinear input without knowing future power draw. And as far as predictability goes for batteries...
it goes down when I unplug it
it goes down faster when it gets used (in the case of a phone) or it gets hot/loud (in the case of a laptop)
I don't have a citation for this, but I believe a lot of batteries that can self-report their charge also naturally go "bad" over time if used improperly. If a battery is typically left 100% charged (e.g. if you leave your phone/laptop in the charger all the time), the chemical composition will slowly train it to act as though it's running out faster (but it will last longer than expected, once visibly "drained"). Hence why with certain electronics, you are recommended to go through as much of a "full cycle" as possible before recharging.
I am attempting to ensure (to a reasonable extent- I don't drive a semi) that I will either be bigger, or almost as big, as any car I will be in an accident with.
Gee, thanks, I appreciate your concern for your fellow mankind (those of us who don't have truck-sized vehicles).
Hmm, good point. I'm used to thinking in terms of passwords, where it works (because the input set size is much greater). Hashes are worthless for SSNs because it boils down to requiring a private key, at which point it's probably better to refer to it as "encryption", not "hashing".
The strength of your encryption means nothing in the face of a user who insists on... keep[ing] a post-it on their computer monitor.
What's so bad about that? There is a certain level of privacy expected in the workplace. If the company has an issue with a snooping ronin employee, audit trails should reveal it pretty quickly, and result in a swift termination. It is a fact of life that not everyone will remember every password they are bombarded with, so it's stupid to fight it. Just find the least damaging alternative... like having them write their password on a $50 bill (since people are pretty good at keeping money safe, when compared to post-it-notes). It turns "something you know" into "something you have".
You're supposed to send the salt around with the encrypted result. The point of the salt is not to be secret, but to add new sources of variance to the hash, making it harder to reverse-engineer (and impossible to trivially detect duplicate SSNs/passwords).
You also need a different salt added to every SSN. If you're adding the same salt everywhere, you are worse off because the consistency makes it easier to reverse the hashing algorithm. This is essentially what caused WEP to be broken so easily.
I've used that exact method for user management while working with a team of inexperienced developers (I was the de-facto DBA). Because of that, I was able to implement password hashing without exposing it to the app developers, so they never had a chance to botch password management.
...we had 8 separate MySQL instances running on 8 different ports... I never did get a good explanation why the admin set it up that way.
Maybe because it kept the admin employed? Maintaining a Rube Goldberg setup is a form of corporate ransom, and it keeps you employed until you lose your leverage.
if another attack on the scale of 9/11 to happen...
...and it will happen eventually. It's not a matter of "if".
...would you want the government not passing any laws to catch the culprits or for them to be too scared of losing $$$ to do anything?
I don't want "the government" to have to pass any more laws to catch the culprits. It's not like new laws need to exist in order to deal with a mass homicide perpetrated against anonymous individuals. I want the executive branch and the military to mobilize and do their job by enforcing existing laws at both a national and international level.
The desire to let men in power create more laws after shocking events is a great way to lose our freedom. Of course, shocking events happen, and it's a great time to slip in something that seems superficially related, but is nothing more than good timing for a political hobby horse.
I've heard described the difference between "Agile" and "agile". The lowercase "agile" merely refers to the goal of embracing change with software development without losing efficacy. This is a good goal, regardless of how you do it. The uppercase "Agile" always refers to someone's attempted implementation of the former, and is generally a disaster and/or sham. This description is consistent with what I've seen so far.
Slashdot Mirror
Not sure if this is relevant to your situation, but I've found that GNU std::list sucks compared to almost any other data structure. Never bothered to check why, I now just try to avoid it. Sorry, but you happened to stumble upon the worst of the lot.
If you think you can beat std::vector... good luck. You won't, for any non-POD type.
Everyone says that about every piece of technology until they discover something better. Even if it's ultimately not successful, I find it commendable that the KDE devs are willing to try something new.
No they don't. They have an obligation to weigh the cost of your bad publicity and lost business against the cost of fixing the bug, and then do whatever makes more sense for themselves. And the answer will most likely be "screw you" unless everyone else is having the same problem.
You, as an individual consumer of a piece of software from MS or Apple, don't have the power you think you do.
Do my eyes deceive me, or are you using binary for those version numbers?
I hate to burst your bubble, but negative values in the standard RGB spectrum are physically possible. So yeah, negative-red would give you a blacker black, if the output medium had a wide enough gamut.
Yeah, they probably should have gone with "KDE-Core-4.0" and only bundled the necessary applications. But it still would have caught flak from people, since whatever word you use (Core, Libs, whatnot) will still be ignored by a vocal minority.
I think you're missing the point that 4.0 was stable for developers. For a desktop environment with a big hairy dependency chain and massive internal churn, providing a stable library release is a critical step to help application developers. The alpha/beta/rc terminology doesn't work so well when the ultimate goal is releasing 1/2 of the platform.
It would have been interesting if they had decided to call it "4.-1", though.
In open-source projects, whole numbers also generally suggest more aggressive churn, which means more bugs. I think it's pretty common for *.0 releases to have weird new bugs. KDE just pushed that to the next level by making sure some of those bugs were "application X does not exist yet".
What? It's not like this is some sort of failing of Linux. If a website is using User-Agent sniffing, and it rejects anything it doesn't think is MSIE, it's the fault of the website for not working, not the browser.
Your comment is akin to blaming Richard for being banned from accessing the "Todds Only" grocery store. It's his fault for not being Todd! Right?
I'm pretty sure it violates some truth-in-advertising laws as well. Hence the switch (by AT&T) to the cushy-feel-good "more bars in more places". Impossible to argue against a meaningless metric!
I think the point of the GP is that you're in the (high-maintenance) minority for demanding linear output from nonlinear input without knowing future power draw. And as far as predictability goes for batteries...
Never had an exception yet!
This one goes to eleven.
I don't have a citation for this, but I believe a lot of batteries that can self-report their charge also naturally go "bad" over time if used improperly. If a battery is typically left 100% charged (e.g. if you leave your phone/laptop in the charger all the time), the chemical composition will slowly train it to act as though it's running out faster (but it will last longer than expected, once visibly "drained"). Hence why with certain electronics, you are recommended to go through as much of a "full cycle" as possible before recharging.
Hey! He said "Midwest", not "Midwest (redneck)"!
Gee, thanks, I appreciate your concern for your fellow mankind (those of us who don't have truck-sized vehicles).
Hmm, good point. I'm used to thinking in terms of passwords, where it works (because the input set size is much greater). Hashes are worthless for SSNs because it boils down to requiring a private key, at which point it's probably better to refer to it as "encryption", not "hashing".
What's so bad about that? There is a certain level of privacy expected in the workplace. If the company has an issue with a snooping ronin employee, audit trails should reveal it pretty quickly, and result in a swift termination. It is a fact of life that not everyone will remember every password they are bombarded with, so it's stupid to fight it. Just find the least damaging alternative... like having them write their password on a $50 bill (since people are pretty good at keeping money safe, when compared to post-it-notes). It turns "something you know" into "something you have".
You're supposed to send the salt around with the encrypted result. The point of the salt is not to be secret, but to add new sources of variance to the hash, making it harder to reverse-engineer (and impossible to trivially detect duplicate SSNs/passwords).
You also need a different salt added to every SSN. If you're adding the same salt everywhere, you are worse off because the consistency makes it easier to reverse the hashing algorithm. This is essentially what caused WEP to be broken so easily.
I've used that exact method for user management while working with a team of inexperienced developers (I was the de-facto DBA). Because of that, I was able to implement password hashing without exposing it to the app developers, so they never had a chance to botch password management.
Coming from a Postgres background, trying to use stored procedures in MySQL are awful.
Worst of the bunch is that you can't return recordsets from stored procedures, meaning there's no ability to use them as "parameterized views".
That's your problem right there. There is no value in "wanting" OOD aside from a personal learning experience.
Why aren't you using PDO? Let the database driver escape everything for you.
Maybe because it kept the admin employed? Maintaining a Rube Goldberg setup is a form of corporate ransom, and it keeps you employed until you lose your leverage.
I don't want "the government" to have to pass any more laws to catch the culprits. It's not like new laws need to exist in order to deal with a mass homicide perpetrated against anonymous individuals. I want the executive branch and the military to mobilize and do their job by enforcing existing laws at both a national and international level.
The desire to let men in power create more laws after shocking events is a great way to lose our freedom. Of course, shocking events happen, and it's a great time to slip in something that seems superficially related, but is nothing more than good timing for a political hobby horse.
I've heard described the difference between "Agile" and "agile". The lowercase "agile" merely refers to the goal of embracing change with software development without losing efficacy. This is a good goal, regardless of how you do it. The uppercase "Agile" always refers to someone's attempted implementation of the former, and is generally a disaster and/or sham. This description is consistent with what I've seen so far.