You betcha! I'm sure that the hammer will come down as soon as "the powers that be" realize that no matter what DRM or other nasty stuff they come up with - it'll run in emulated machines.
For example, you could run QEmu and some sort of nasty DRM audio app like Napster. While it's running in the VM, drop back to windows and cat/dev/dsp into a file.
Well, in a lot of ways that's like asking what's the best tool in your toolbox? It depends on what you're trying to do. Hammer a nail, use a hammer. Tighten a bolt, use a wrench. A wrench makes a lousy hammer and a hammer makes a lousy wrench.
Wine is great for running x86 Windows apps natively on Linux. It has no Microsoft code in it whatsoever - that's it's advantage. No MS tax to run MS apps. Downside is that it isn't 100% accurate - some apps don't work. By its very nature it'll always be a work in progress.
Qemu (and VMware and their like) emulate a complete computer. They're slower because they have to emulate hardware. And to run Windows apps, you'll need a copy of a Microsoft OS, so you've got a licensing issue there. As a plus, you can do development on a virtual machine and cause any kind of damage, and (if you've backed up before you tried it), fixing things is as simple as tar -xvzf yourbackup.tgz.
Explore both options a bit and you'll find that each one solves a particular class of problems. More tools in the toolbox is always good.
Not really sure how you'd go about hobbying around with one. We bought 3 devboards (DbAu1100) directly from AMD, and IIRC they were over $1000 each. But that was over a year ago. Might have changed by now.
It's a shame there's not something like the LART StrongArm board for the Alchemy yet. They're really great processors. I had one running an Xorg X server and the IFS screensaver (which takes the CPU to 100%) all day, and it was still cooler than a cup of coffee. Barely even warm, really.
Here is an already-in-the-market device that uses the Au1100. It's an automotive scantool by Chrysler. Note the article is dated May 5, 2004. They were in production at the time.
What's that you say? It wasn't in the book? Oh. Then it sucked
Was the scene cool? Sure. Elves fighting = teh cool. You know what would have made it better? Dragons. Dragons are cool, right? Add some dragons. And some dwarves to fight the dragons. Maybe a balrog, too! Yeah! Now it's totally awesome!!
And nevermind the fact that one of the themes Tolkien tried to express was that the end of the Third Age was the age of men, and not elves. They had their time in Middle Earth and were leaving. Let's ignore that and just call it Lord of the Rings: Extreme Edition. Yeah. That'll totally rule.
Anyways, back on topic - I know that directors do occasionally have to make small changes so that a scene will "read" a little better. But bizarre changes that translate into "if I had wrote this I'd have done this instead of that" are not excusable. Write your own damn story if that's what you want to do, but don't attach the original author's name onto it - it's not their story you're telling.
True enough, but look at the 5 day. Only thing I missed was the 3 day wait.
The stock drops below 4.2, there's a huge mass of activity, and the price starts going back up again. Keep watching - the bizarre Darl announcement is coming any moment now.
Betcha SCO is overjoyed. For real! Here's what'll happen next.
Upon hearing the bad news, SCO's stock will begin to tank. Again. And once it gets low enough, SCO-friendly folks will buy a pile of it.
And then Darl will release some outlandish press release, saying that they own the rights to American Cheese or the number 6, and the stock will rise again. After all, they just can't make these claims without something up their sleeve, can they? Three days later, everybody sells. And then waits for the next bit of tangy pseudo-bad-news-for-SCO goodness.
What I want to know is when some judge will finally step in and put and end to this fraud.
Well, there's lots of different foods out there. How did you pick your favorites?
Try a few. Download a few distros. Don't worry - they're free. Load them on a machine and fiddle with them. You'll find that one of them out there matches the way you work and think. All you have to do is fiddle around a bit and find it.
And don't worry about the "they're all different" bit. They're really not so different. Every distro is about 80% identical to other distros. The main differences are installation and package management.
The reason why forking isn't a problem is because the open source community knows how to read the friggin' RFCs before we code something. Unlike a certain software giant who lives in Redmond.
Doesn't matter if there is one branch of a big project or 1000 forks. If they stick to specs, they are all interchangeable. Like your window manager. As long as they do what they're supposed to do, stick to specs and play fair - it doesn't matter which one you use.
This gives the user choice, which is why MS finds it to be such an alien concept.
I like 10am-bedtime's answer, but I'd also like to add in my two cents.
First, software creation is different than 99.9% of the other products out there. Software, unlike a lot of other physical-world objects can fail to work at all if they are only 0.01% wrong. If your tires aren't perfectly round they still roll. If the spark plugs are off by a little bit, they still spark. If you have a JMP statement that is off by a single byte, the whole thing fails to work.
Another point is that software is not like bricklaying. You can't take the same approach. "One bricklayer can place 60 bricks an hour. So in a wall with 600 bricks, that's 10 hours. Two guys should be able to do it in five."
A software team also has the problem of self-complexity to overcome. Do my changes cause problems with everyone else's changes? I recommend reading The Mythical Man-Month for a better understanding of that side of it.
Ever-increasing presence of high-tech devices in modern cars is a double-edged sword, the New York Times discovers.
The problem the NYT is describing here is not high-tech devices. The problem is crappy firmware.
The auto industry is driven by release dates. The release date for the '06 version of your favorite car is already determined by the industry. Doesn't matter if it's not 100%, it ships that day, regardless.
This is not the best environment to create software in. Hence, you get crappy firmware and that's where those 30% of service calls come from. Believe me, if the auto industry wanted to make bullet proof firmware, the tools are out there (think Mars Rover and VxWorks for example). But the service calls cost less than the development effort, and the end result is - crappy firmware.
...you just have to find a way to mask the design somehow
Easily done. Head to Techniks or some other similar place and get some Press 'n Peel PCB transfer film.
Draw what you want to etch as a negative and then iron it onto your metal. Dip the whole thing in the acid bath and wait a bit. Steel wool to clean off the resist and that should do it.
If anyone ever uses the TCO argument on why they lean on MS products, point to Brazil. With the economic problems they have, they have to make smart decisions. And they went with Open Source.
It's an excellent proof of Open Source having the lower TCO.
Use STL's string library, or do what MS did and use functions with better semantics for handling error cases.
Those are possible solutions. Here's another one. Use strncpy() and don't forget you need +1 char for the trailing zero.
strncpy() can create strings which are not nul terminated. It also is inefficient, as it fills the rest of the space with nul padding.
A non null terminated string can cause a crash. True. But an unterminated copy can cause overruns and run malicious code, which is worse. I still fail to see how strncpy() could *ever* be worse than strcpy().
Because not all buffer overruns are caused by misuse of the string library.
Show me where I said that.
In fact - given that it gets so much bad press - I'd say that nearly none of them are caused by that these days.
Nearly? Then this does still happen every so often? So it's safe to say that MS is still having issues with these kinds of overruns?
...strncpy instead of strcpy, which actually causes more problems than it solves.
And the correct solution would be? Or do you simply enjoy bitching about things? Also, show me exactly how strncpy() causes more problems than strcpy(). It's not perfect, but it couldn't possibly be worse than an unbounded copy.
For bonus points you can explain to the class why MS keeps having buffer overrun exploits, especially since they uber-fixed their library and all.
The original poster was not lying, the original poster simply doesn't waste his limited time on Earth reading MS blogs. All the original poster was trying to illustrate is that there are still buffer overrun exploits thatkeephappening, and wanted to illustrate that fact simply without writing a thesis.
Slashdot Mirror
You betcha! I'm sure that the hammer will come down as soon as "the powers that be" realize that no matter what DRM or other nasty stuff they come up with - it'll run in emulated machines.
For example, you could run QEmu and some sort of nasty DRM audio app like Napster. While it's running in the VM, drop back to windows and cat /dev/dsp into a file.
But what, exactly, is best?
Well, in a lot of ways that's like asking what's the best tool in your toolbox? It depends on what you're trying to do. Hammer a nail, use a hammer. Tighten a bolt, use a wrench. A wrench makes a lousy hammer and a hammer makes a lousy wrench.
Wine is great for running x86 Windows apps natively on Linux. It has no Microsoft code in it whatsoever - that's it's advantage. No MS tax to run MS apps. Downside is that it isn't 100% accurate - some apps don't work. By its very nature it'll always be a work in progress.
Qemu (and VMware and their like) emulate a complete computer. They're slower because they have to emulate hardware. And to run Windows apps, you'll need a copy of a Microsoft OS, so you've got a licensing issue there. As a plus, you can do development on a virtual machine and cause any kind of damage, and (if you've backed up before you tried it), fixing things is as simple as tar -xvzf yourbackup.tgz.
Explore both options a bit and you'll find that each one solves a particular class of problems. More tools in the toolbox is always good.
The story is posted on Reuters, and does not require a free registration to read it.
Not really sure how you'd go about hobbying around with one. We bought 3 devboards (DbAu1100) directly from AMD, and IIRC they were over $1000 each. But that was over a year ago. Might have changed by now.
It's a shame there's not something like the LART StrongArm board for the Alchemy yet. They're really great processors. I had one running an Xorg X server and the IFS screensaver (which takes the CPU to 100%) all day, and it was still cooler than a cup of coffee. Barely even warm, really.
Here is an already-in-the-market device that uses the Au1100. It's an automotive scantool by Chrysler. Note the article is dated May 5, 2004. They were in production at the time.
Daimler-Chrysler scantool link.
I've had an Alchemy Au1100 devboard on my desk for over a year. The disk that came with the devboard is dated 1-27-2003.
There is already a very complete Linux port mostly done by Montavista.
What's that you say? It wasn't in the book? Oh. Then it sucked
Was the scene cool? Sure. Elves fighting = teh cool. You know what would have made it better? Dragons. Dragons are cool, right? Add some dragons. And some dwarves to fight the dragons. Maybe a balrog, too! Yeah! Now it's totally awesome!!
And nevermind the fact that one of the themes Tolkien tried to express was that the end of the Third Age was the age of men, and not elves. They had their time in Middle Earth and were leaving. Let's ignore that and just call it Lord of the Rings: Extreme Edition. Yeah. That'll totally rule.
Anyways, back on topic - I know that directors do occasionally have to make small changes so that a scene will "read" a little better. But bizarre changes that translate into "if I had wrote this I'd have done this instead of that" are not excusable. Write your own damn story if that's what you want to do, but don't attach the original author's name onto it - it's not their story you're telling.
Uh... Darmok and Jalad at Tanagra?
No, but kudos for out-geeking me. ;^)
But Peter Jackson's version of The Lord of the Rings has made me change my mind. I think it can be good.
This is going to get me modded +5, Comic Book Guy, but here goes anyways.
Elves. At. Helms. Deep.
Try one of these. Or these.
True enough, but look at the 5 day. Only thing I missed was the 3 day wait.
The stock drops below 4.2, there's a huge mass of activity, and the price starts going back up again. Keep watching - the bizarre Darl announcement is coming any moment now.
Betcha SCO is overjoyed. For real! Here's what'll happen next.
Upon hearing the bad news, SCO's stock will begin to tank. Again. And once it gets low enough, SCO-friendly folks will buy a pile of it.
And then Darl will release some outlandish press release, saying that they own the rights to American Cheese or the number 6, and the stock will rise again. After all, they just can't make these claims without something up their sleeve, can they? Three days later, everybody sells. And then waits for the next bit of tangy pseudo-bad-news-for-SCO goodness.
What I want to know is when some judge will finally step in and put and end to this fraud.
I work in a small, overworked and understaffed IT department at a profitable business.
Well, there's lots of different foods out there. How did you pick your favorites?
Try a few. Download a few distros. Don't worry - they're free. Load them on a machine and fiddle with them. You'll find that one of them out there matches the way you work and think. All you have to do is fiddle around a bit and find it.
And don't worry about the "they're all different" bit. They're really not so different. Every distro is about 80% identical to other distros. The main differences are installation and package management.
Just jump in and see what suits you.
The reason why forking isn't a problem is because the open source community knows how to read the friggin' RFCs before we code something. Unlike a certain software giant who lives in Redmond.
Doesn't matter if there is one branch of a big project or 1000 forks. If they stick to specs, they are all interchangeable. Like your window manager. As long as they do what they're supposed to do, stick to specs and play fair - it doesn't matter which one you use.
This gives the user choice, which is why MS finds it to be such an alien concept.
I like 10am-bedtime's answer, but I'd also like to add in my two cents.
First, software creation is different than 99.9% of the other products out there. Software, unlike a lot of other physical-world objects can fail to work at all if they are only 0.01% wrong. If your tires aren't perfectly round they still roll. If the spark plugs are off by a little bit, they still spark. If you have a JMP statement that is off by a single byte, the whole thing fails to work.
Another point is that software is not like bricklaying. You can't take the same approach. "One bricklayer can place 60 bricks an hour. So in a wall with 600 bricks, that's 10 hours. Two guys should be able to do it in five."
A software team also has the problem of self-complexity to overcome. Do my changes cause problems with everyone else's changes? I recommend reading The Mythical Man-Month for a better understanding of that side of it.
Ever-increasing presence of high-tech devices in modern cars is a double-edged sword, the New York Times discovers.
The problem the NYT is describing here is not high-tech devices. The problem is crappy firmware.
The auto industry is driven by release dates. The release date for the '06 version of your favorite car is already determined by the industry. Doesn't matter if it's not 100%, it ships that day, regardless.
This is not the best environment to create software in. Hence, you get crappy firmware and that's where those 30% of service calls come from. Believe me, if the auto industry wanted to make bullet proof firmware, the tools are out there (think Mars Rover and VxWorks for example). But the service calls cost less than the development effort, and the end result is - crappy firmware.
So, what's the MS marketing spin that says their search is better than Google? What's Bill's reason for me to switch?
Easily done. Head to Techniks or some other similar place and get some Press 'n Peel PCB transfer film.
Draw what you want to etch as a negative and then iron it onto your metal. Dip the whole thing in the acid bath and wait a bit. Steel wool to clean off the resist and that should do it.
If you're really cheap, toner is a decent resist. No different than making a homebrew PCB.
Nice to see someone else can read between the lines of Microsoft's bogus TCO studies.
If anyone ever uses the TCO argument on why they lean on MS products, point to Brazil. With the economic problems they have, they have to make smart decisions. And they went with Open Source.
It's an excellent proof of Open Source having the lower TCO.
Use STL's string library, or do what MS did and use functions with better semantics for handling error cases.
Those are possible solutions. Here's another one. Use strncpy() and don't forget you need +1 char for the trailing zero.
strncpy() can create strings which are not nul terminated. It also is inefficient, as it fills the rest of the space with nul padding.
A non null terminated string can cause a crash. True. But an unterminated copy can cause overruns and run malicious code, which is worse. I still fail to see how strncpy() could *ever* be worse than strcpy().
Because not all buffer overruns are caused by misuse of the string library.
Show me where I said that.
In fact - given that it gets so much bad press - I'd say that nearly none of them are caused by that these days.
Nearly? Then this does still happen every so often? So it's safe to say that MS is still having issues with these kinds of overruns?
And the correct solution would be? Or do you simply enjoy bitching about things? Also, show me exactly how strncpy() causes more problems than strcpy(). It's not perfect, but it couldn't possibly be worse than an unbounded copy.
For bonus points you can explain to the class why MS keeps having buffer overrun exploits, especially since they uber-fixed their library and all.
...how much extra does the media cost that'll let you write to the label side?
That's a helluva good link, def. Mods need to send a few points your way...people need to read that. Showed me a few things I didn't know. =)
The original poster was not lying, the original poster simply doesn't waste his limited time on Earth reading MS blogs. All the original poster was trying to illustrate is that there are still buffer overrun exploits that keep happening, and wanted to illustrate that fact simply without writing a thesis.