I recommend Linux or Mac to everyone nowadays. Linux for folks who to the basic stuff -- email, web, etc, and Mac for people who want apps like Quickbooks, invoicing software, and other more niche apps. I wish I could recommend Linux for those things too, but sadly, such software in Linux is either really rough around the edges or simply doesn't exist.
Oh, I've met them, but they're usually people who have been there a thousand years and are just waiting to retire. I'm not worried about them, and usually, neither is management. We're trying to make the company better for the future, which these people simply are not part of.
In smaller places, this is a little more difficult because the politics are a bit different. Either way, sometimes the way to deal with these people is to just ignore them, make as much progress as you can without their help, and if it comes down to it, mention to their boss that they're impeding a high-value project. Put it nicely, spin it non-confrontationally, but just put it out there that this person isn't cooperating. If they can see the value of what you're doing, the problem will usually resolve itself.
The markup is a bit rough, but they do have some javascript buttons for the more common stuff. Trouble is that it inserts all of the markup visibly into the document.
I keep expecting people to come back and tell me it sucks, and they haven't (yet). I figure if the friggin world can figure out Wikipedia, they can just as easily manage my copy of the same software.
I started a job as a IT supervisor about 6 months ago. There was very little useful documentation, and very little in the way of process. Everything was locked up in peoples' heads. The results?
Extreme pain when someone goes on vacation
Every time a particular issue comes up, that person has to drop what they're doing and go work on it, even if it isn't really their job description anymore.
Very little confidence that we're doing the right thing when that person is away.
Ludicrous amounts of time spent investigating something that a person could have told us easily.
We had two very experienced people leave in the space of two weeks, and another follow shortly thereafter. Most of the people on my team are pretty new, and we had a hell of a time trying to make up for the knowledge that walked out the door.
So what did I do?
Set up MediaWiki, of course. Initially, upper management was skeptical and slightly against, but I did it in my spare time and populated a couple hundred documents into it myself. It took days of boring, tedious work, copying from disparate sources, grabbing emails with useful information and making them into a coherent document...
The end result was something that, when I showed to the same upper management, they jumped. They made it standard operating procedure to document our processes, and even expanded the site to serve other departments. Amazing, considering it's only been around 3 to 4 months at this point.
Look, I know people say that docs "decrease their value", but that statement isn't worth its weight in horse shit. The fact is that, if you are an intelligent, useful person, your value is in *improving* the process or product. If you're stuck doing the same thing over and over like a farking monkey, then you're not really worth much more than a farking monkey. Eventually your "vendor lockin" will become obsolete, and then you won't be worth a thing. A genuinely helpful, useful person can simply go on to the new thing and help make that better too.
I was just in my home state of Pennsylvania yesterday and saw a bumper sticker asking "Why not coal?" (Coal Miner's Union) The major industry around my area used to be anthracite mining, and when that collapsed, the town kinda went to shit, although it's coming back slowly. Given that, I understand why they'd want coal, just like I'm sure people in Detroit want the auto industry back, and the midwest wants ethanol.
Unfortunately, even though it would probably be a boon to my home town, I can't agree with bringing back coal. All of the evidence just seems to point to critical public safety issues due to the inevitable pollution. I'm a believer that, when the world changes, you change with it. Re-educate, find something else to do, and go do it. This resistance to change is what keeps communities poor in the global economy, and creates lobbies to bring back technologies and industries that are probably better off dead or significantly re-structured.
Over the past few decades, however, a series of studies has called these stereotypes into question. Among the surprising conclusions: the waste produced by coal plants is actually more radioactive than that generated by their nuclear counterparts. In fact, fly ash--a by-product from burning coal for power--contains up to 100 times more radiation than nuclear waste.
At issue is coal's content of uranium and thorium, both radioactive elements. They occur in such trace amounts in natural, or "whole," coal that they aren't a problem. But when coal is burned into fly ash, uranium and thorium are concentrated at up to 10 times their original levels.
Sure, except that temporary measures are very seldom temporary. They wind up being part of a baseline that people just assume they need to do. Maybe if they name the meta header "X-IE8-Compat-Kludge-Dont-Use-After-2010" does stuff like this stand any chance of actually going away.
I know you're just being snarky, but really, the database itself is probably not the problem. Apart from the fact that they can't seem to decide if it's an order management screw-up or short supply (or both), any "database" error was more likely in the application used to track the orders. Even if that's an OSS application, the number of eyeballs will probably be much lower than your average OSS database.
IF MS were to change the way pages rendered with existing doctypes, millions of pages could/would render differently requiring businesses and individuals across the world to either re-vamp their websites or at least change the existing doctype to a new name that referred to the old rendering style.
So what? Seriously. If it's important, it'll get fixed in a hurry. If it's not important, who cares?
Besides, I hear this sort of talk all the time. This Y2K-esque "end of the world if we make one mistake" mentality is extremely prevalent in IT departments, where people are trying to predict "worst case scenarios". Usually they wind up WAAAAAY overestimating the impact, and only really succeed in dog-locking themselves into a piss-poor environment where they're afraid to change anything. Sometimes you have to take a risk if you're ever going to move ahead. "What if" and "I bet it'll break..." only sink your tires deeper into the mud of perceived helplessness.
Any anger at MS for "breaking the web" (allowing for a bit of self-aggrandizement) will be short lived, AS LONG AS THEY DO IT RIGHT THIS TIME, and don't create another steaming pile in the process. Using this sort of tagging is a graceless solution brought about by an overinflated fear of consequences that simply won't matter. I don't care if it is "standard HTML", it's being used in a way that will make sites even more complicated to maintain.
If MS truly wants to avoid "breaking the web" (I can't even type it with a straight face), they'll release lots previews leading up to the official release. I'm talking "nightly build" style. That way when sites do break, they can just say they gave ample opportunity and can do no more. Any company with a web department worth its salt will be testing these builds at least once every month to make sure nothing crazy happens that they'll need to address.
Come on, MS, I know it hurts, but take a cue from Open Source. Release early and often, and this crap won't happen.
(PS -- when I say "self aggrandizement", I'm referring to this notion that Microsoft feels they bear the weight of the web on their shoulders, when, in reality, it's in all companies' best interest to ensure that testing and modifications are done BEFORE MS pushes the IE8 update pack. MS doesn't need to feel they're solely responsible, as long as they allow enough lead time for others to make required changes.)
Besides, the only sites that offer any issues these days are corporate intranet/Appliance administration sites anyways.
Absoutely true. Most of the code out there that will break immediately are probably not professional sites (and therefore only lightly trafficked). They'll be personal sites for the most part with some small business sites thrown in. The first probably won't notice, and the second will get it fixed.
Our company is still on IE6, and they don't move anything without testing for a long time. Intranet sites will be fixed long before IE8 ever hits corporate workstations. Besides, even in our firm, we have lots of unofficial installs of FF, and almost everything works just fine. The ones that don't can be fixed in pretty short order.
I understand you're including "copyrights are signed back to the company", but this isn't standard in the GPLv3, is it? I haven't read it through, but this phrase would seem out of place. More like an addendum from the copyright holder.
That would mean that straight GPLv[23] software doesn't work that way. The copyright belongs to all of the contributors, not just the author. They'd also have to agree that contributions added by the acquiring company can be kept secret (if distributed) because they contributed to the project under those terms.
I agree with you, but want to add the obvious that impatience is not restricted to young people. I'm a first-level manager at work (I'm 28). I've been working in IT for about 7 years now (and yes, TheGoogle is all the library I need). I find that the people above me, generally in their 40s and 50s, want major changes, significant development or infrastructure changes, to happen within a week. When I tell them it isn't possible, they seem to think it's because I'm lazy or something.
I think the point is that nobody likes to wait for what they want, but they tend to get less frustrated when they know there's no faster way to get it. Quite the opposite when they know they could have the information in three seconds without leaving their chair, but instead they need to devote the afternoon in the dead tree forest.
The trick is to make people realize that one is not a substitute for the other, when each is appropriate, and how to tell when an internet site or a book is not trustworthy. (Remember that crackpots write books too -- it's not solely a problem for the internet.) When people realize that these two methods supplement each other, they'll tend to be much more patient because they'll understand *why* they have to find a dead tree version, and why the Internet information is insufficient.
The other point is that there's no reason that medium really makes a difference. If the dead-tree version has been digitized, then there's no shame in getting it from the internet instead of the library. Can I find out who assassinated Kennedy from someone's blogs? No, but I might be able to find relevant clues in a digitized version of Jackie O's memoirs.
The great thing is that we've got a bunch of MS Access "applications" that we can't get funding to re-write properly. Once Office doesn't support VBA, they'll have no choice. We'll then migrate them to unix land and probably Sybase, Oracle, or Postgres.
Allowing business users to have Access is like giving an unsupervised 6 year old a handgun. They can work it, but they have no idea how to be responsible with it and will probably do much more harm than good.
novel method is presented for inaudibly hiding information in an audio signal by subtly applying time-scale modification to seg- ments of the signal. The sequence, duration, and degree of the time-scale modifications are the parameters which encode infor- mation in the altered signal. By comparing the altered signal with a reference copy, compressed and expanded regions can be identi- fied and the hidden data recovered. This approach is novel and has several advantages over other methods: it is theoretically noise- less, it introduces no spectral distortion, and it is robust to all known methods of reproduction, compression, and transmission.
You mean the ones like were involved with the ongoing DRM Fiasco, CSS, and the Sony rootkit? You might want to reserve your praise a bit.
Ok, so the encoding mechanism is timescale data instead of bit twiddling on the left channel. The decoding of this still assumes that the file hasn't been compared and averaged with another copy or three.
What happens if I take my timescale encoding method and mix it up, average the values, or arbitrarily re-set the timescale information in areas that the timescale data doesn't match with other files? Maybe I even throw in a few random new ones just for fun. Consider this:
If I just tell you "5", how do you know the original contributing addends? Worse, what if you know that the answer should have been "3", not "5", and you don't even know how many numbers were used? Same if I give you a file that contains or is modified by the timescale modifications from multiple files. You know there are differences and can find them, but there are more than there should be, or they're not the values you're expecting.
The point is that, if you can find the information, you can destroy it or make it completely useless. This destruction of data that is necessarily impossible to hear will be inconsequential to the subjective quality of the data.
I'm no cryptographer or mathematician, but even I can see where this is possibly flawed. The weakness is that they considered each file in isolation, not based on functionality that can be implemented in peer-to-peer networks.
I would think it's possible to detect using two watermarked as well.
Think about this as a watermark:
1234JustShootMe567 1234CrazedWalrus567
1234567 doesn't identify anyone, and I've found and removed the portion of the code that differentiates you or me. If the watermark is tied to the user, then that part of it is necessarily different. This assumes that the file is not re-encoded for every user before adding the watermark. Doing so would be a major detriment to scalability, so I doubt that could be done.
Even if it is encrypted, it would have to be placed in an area of the music that isn't significant -- maybe a least-significant-bit of one channel or something -- or you'd hear it. If that's the case, then if you have two files from two different users, you can bitwise-or, zero-out, or otherwise destroy the information wherever the bits differ between the files. Since they're necessarily in an insignificant part of the signal, the music probably won't sound noticeably different.
I just think this sounds incredibly weak. If people can break encryption and decode entire streams, there are going to be ways to strip these watermarks -- probably the day the first song that contains it is released.
Slashdot Mirror
I recommend Linux or Mac to everyone nowadays. Linux for folks who to the basic stuff -- email, web, etc, and Mac for people who want apps like Quickbooks, invoicing software, and other more niche apps. I wish I could recommend Linux for those things too, but sadly, such software in Linux is either really rough around the edges or simply doesn't exist.
Just... you know... out of curiosity...
Oh, I've met them, but they're usually people who have been there a thousand years and are just waiting to retire. I'm not worried about them, and usually, neither is management. We're trying to make the company better for the future, which these people simply are not part of.
In smaller places, this is a little more difficult because the politics are a bit different. Either way, sometimes the way to deal with these people is to just ignore them, make as much progress as you can without their help, and if it comes down to it, mention to their boss that they're impeding a high-value project. Put it nicely, spin it non-confrontationally, but just put it out there that this person isn't cooperating. If they can see the value of what you're doing, the problem will usually resolve itself.
The markup is a bit rough, but they do have some javascript buttons for the more common stuff. Trouble is that it inserts all of the markup visibly into the document.
I keep expecting people to come back and tell me it sucks, and they haven't (yet). I figure if the friggin world can figure out Wikipedia, they can just as easily manage my copy of the same software.
Don't worry, the brainless never truly dies.
I started a job as a IT supervisor about 6 months ago. There was very little useful documentation, and very little in the way of process. Everything was locked up in peoples' heads. The results?
We had two very experienced people leave in the space of two weeks, and another follow shortly thereafter. Most of the people on my team are pretty new, and we had a hell of a time trying to make up for the knowledge that walked out the door.
So what did I do?
Set up MediaWiki, of course. Initially, upper management was skeptical and slightly against, but I did it in my spare time and populated a couple hundred documents into it myself. It took days of boring, tedious work, copying from disparate sources, grabbing emails with useful information and making them into a coherent document...
The end result was something that, when I showed to the same upper management, they jumped. They made it standard operating procedure to document our processes, and even expanded the site to serve other departments. Amazing, considering it's only been around 3 to 4 months at this point.
Look, I know people say that docs "decrease their value", but that statement isn't worth its weight in horse shit. The fact is that, if you are an intelligent, useful person, your value is in *improving* the process or product. If you're stuck doing the same thing over and over like a farking monkey, then you're not really worth much more than a farking monkey. Eventually your "vendor lockin" will become obsolete, and then you won't be worth a thing. A genuinely helpful, useful person can simply go on to the new thing and help make that better too.
+10 Scary Sh*t
It's also the currency symbol for "Norwegian krone".
http://www.google.com/search?hl=en&q=NOK&btnG=Google+Search
Any time.
I was just in my home state of Pennsylvania yesterday and saw a bumper sticker asking "Why not coal?" (Coal Miner's Union) The major industry around my area used to be anthracite mining, and when that collapsed, the town kinda went to shit, although it's coming back slowly. Given that, I understand why they'd want coal, just like I'm sure people in Detroit want the auto industry back, and the midwest wants ethanol.
Unfortunately, even though it would probably be a boon to my home town, I can't agree with bringing back coal. All of the evidence just seems to point to critical public safety issues due to the inevitable pollution. I'm a believer that, when the world changes, you change with it. Re-educate, find something else to do, and go do it. This resistance to change is what keeps communities poor in the global economy, and creates lobbies to bring back technologies and industries that are probably better off dead or significantly re-structured.
http://www.sciam.com/article.cfm?id=coal-ash-is-more-radioactive-than-nuclear-waste
Sure, except that temporary measures are very seldom temporary. They wind up being part of a baseline that people just assume they need to do. Maybe if they name the meta header "X-IE8-Compat-Kludge-Dont-Use-After-2010" does stuff like this stand any chance of actually going away.
I know you're just being snarky, but really, the database itself is probably not the problem. Apart from the fact that they can't seem to decide if it's an order management screw-up or short supply (or both), any "database" error was more likely in the application used to track the orders. Even if that's an OSS application, the number of eyeballs will probably be much lower than your average OSS database.
You must be new here.
So what? Seriously. If it's important, it'll get fixed in a hurry. If it's not important, who cares?
Besides, I hear this sort of talk all the time. This Y2K-esque "end of the world if we make one mistake" mentality is extremely prevalent in IT departments, where people are trying to predict "worst case scenarios". Usually they wind up WAAAAAY overestimating the impact, and only really succeed in dog-locking themselves into a piss-poor environment where they're afraid to change anything. Sometimes you have to take a risk if you're ever going to move ahead. "What if" and "I bet it'll break..." only sink your tires deeper into the mud of perceived helplessness.
Any anger at MS for "breaking the web" (allowing for a bit of self-aggrandizement) will be short lived, AS LONG AS THEY DO IT RIGHT THIS TIME, and don't create another steaming pile in the process. Using this sort of tagging is a graceless solution brought about by an overinflated fear of consequences that simply won't matter. I don't care if it is "standard HTML", it's being used in a way that will make sites even more complicated to maintain.
If MS truly wants to avoid "breaking the web" (I can't even type it with a straight face), they'll release lots previews leading up to the official release. I'm talking "nightly build" style. That way when sites do break, they can just say they gave ample opportunity and can do no more. Any company with a web department worth its salt will be testing these builds at least once every month to make sure nothing crazy happens that they'll need to address.
Come on, MS, I know it hurts, but take a cue from Open Source. Release early and often, and this crap won't happen.
(PS -- when I say "self aggrandizement", I'm referring to this notion that Microsoft feels they bear the weight of the web on their shoulders, when, in reality, it's in all companies' best interest to ensure that testing and modifications are done BEFORE MS pushes the IE8 update pack. MS doesn't need to feel they're solely responsible, as long as they allow enough lead time for others to make required changes.)
Absoutely true. Most of the code out there that will break immediately are probably not professional sites (and therefore only lightly trafficked). They'll be personal sites for the most part with some small business sites thrown in. The first probably won't notice, and the second will get it fixed.
Our company is still on IE6, and they don't move anything without testing for a long time. Intranet sites will be fixed long before IE8 ever hits corporate workstations. Besides, even in our firm, we have lots of unofficial installs of FF, and almost everything works just fine. The ones that don't can be fixed in pretty short order.
Hm. Well, I understand the reasoning, I just wasn't aware this was so widespread.
Isn't this issue the other major blocker for the Linux kernel going to GPLv3 (besides Linus)?
I understand you're including "copyrights are signed back to the company", but this isn't standard in the GPLv3, is it? I haven't read it through, but this phrase would seem out of place. More like an addendum from the copyright holder.
That would mean that straight GPLv[23] software doesn't work that way. The copyright belongs to all of the contributors, not just the author. They'd also have to agree that contributions added by the acquiring company can be kept secret (if distributed) because they contributed to the project under those terms.
Where am I wrong here?
I agree with you, but want to add the obvious that impatience is not restricted to young people. I'm a first-level manager at work (I'm 28). I've been working in IT for about 7 years now (and yes, TheGoogle is all the library I need). I find that the people above me, generally in their 40s and 50s, want major changes, significant development or infrastructure changes, to happen within a week. When I tell them it isn't possible, they seem to think it's because I'm lazy or something.
I think the point is that nobody likes to wait for what they want, but they tend to get less frustrated when they know there's no faster way to get it. Quite the opposite when they know they could have the information in three seconds without leaving their chair, but instead they need to devote the afternoon in the dead tree forest.
The trick is to make people realize that one is not a substitute for the other, when each is appropriate, and how to tell when an internet site or a book is not trustworthy. (Remember that crackpots write books too -- it's not solely a problem for the internet.) When people realize that these two methods supplement each other, they'll tend to be much more patient because they'll understand *why* they have to find a dead tree version, and why the Internet information is insufficient.
The other point is that there's no reason that medium really makes a difference. If the dead-tree version has been digitized, then there's no shame in getting it from the internet instead of the library. Can I find out who assassinated Kennedy from someone's blogs? No, but I might be able to find relevant clues in a digitized version of Jackie O's memoirs.
The great thing is that we've got a bunch of MS Access "applications" that we can't get funding to re-write properly. Once Office doesn't support VBA, they'll have no choice. We'll then migrate them to unix land and probably Sybase, Oracle, or Postgres.
Allowing business users to have Access is like giving an unsupervised 6 year old a handgun. They can work it, but they have no idea how to be responsible with it and will probably do much more harm than good.
Actually, the web site "design" was a treat compared to the insanity written on it. Did that guy skip his meds or something? Wow.
It's easy. Just use the last several inches to cover your mouth and nose. That'll be sure to keep all those nasty gases out! Problem solved!
You mean the ones like were involved with the ongoing DRM Fiasco, CSS, and the Sony rootkit? You might want to reserve your praise a bit.
Ok, so the encoding mechanism is timescale data instead of bit twiddling on the left channel. The decoding of this still assumes that the file hasn't been compared and averaged with another copy or three.
What happens if I take my timescale encoding method and mix it up, average the values, or arbitrarily re-set the timescale information in areas that the timescale data doesn't match with other files? Maybe I even throw in a few random new ones just for fun. Consider this:
1 + 1 + 2 + 1 = 5
2 + 1 + 2 = 5
1 + 1 + 1 + 1 + 1 = 5
If I just tell you "5", how do you know the original contributing addends? Worse, what if you know that the answer should have been "3", not "5", and you don't even know how many numbers were used? Same if I give you a file that contains or is modified by the timescale modifications from multiple files. You know there are differences and can find them, but there are more than there should be, or they're not the values you're expecting.
The point is that, if you can find the information, you can destroy it or make it completely useless. This destruction of data that is necessarily impossible to hear will be inconsequential to the subjective quality of the data.
I'm no cryptographer or mathematician, but even I can see where this is possibly flawed. The weakness is that they considered each file in isolation, not based on functionality that can be implemented in peer-to-peer networks.
Hey! That's a great idea!~
Only if she goes from Suck to Blow.
I would think it's possible to detect using two watermarked as well.
Think about this as a watermark:
1234JustShootMe567
1234CrazedWalrus567
1234567 doesn't identify anyone, and I've found and removed the portion of the code that differentiates you or me. If the watermark is tied to the user, then that part of it is necessarily different. This assumes that the file is not re-encoded for every user before adding the watermark. Doing so would be a major detriment to scalability, so I doubt that could be done.
Even if it is encrypted, it would have to be placed in an area of the music that isn't significant -- maybe a least-significant-bit of one channel or something -- or you'd hear it. If that's the case, then if you have two files from two different users, you can bitwise-or, zero-out, or otherwise destroy the information wherever the bits differ between the files. Since they're necessarily in an insignificant part of the signal, the music probably won't sound noticeably different.
I just think this sounds incredibly weak. If people can break encryption and decode entire streams, there are going to be ways to strip these watermarks -- probably the day the first song that contains it is released.