One problem with removing SUID and GUID is it'll break management scripts.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that.
So much for that functionality. Instead, we'll get something worse: people writing binaries that SUID and execute any random shell script, like this:
runsuid --script=/usr/bin/my_script --user=root
Gee, thanks.
Why not get rid of the shell while you're at it? That command line is a security problem waiting to happen. And while you're at it, remove process invocation commands like exec. Those can be used to run executables, which could cause Bad Things to Happen.
What a freaking PITA. I mean, if there was a bug in SUID/GUID handling, fix it. Removing it is really drastic. What's next, removing "rm" because it could delete files?
If your product has a UI, then the design document should start by describing the UI and how all the features work.
If you don't have a UI, then start from the configuration file or command line switches, and do the same thing.
Then you're done. If you can't configure a feature, or can't trigger it from the UI, then it shouldn't exist...unless there are other interaction points.
If you have a network app, document the wire protocol, range of input values, and expected behaviors (of your app and its clients) and outputs.
If it's a distributed system, figure out the different states and document them.
It's actually a pretty simple, though tedious, process. Starting from the UI is a great place, because it shows you instantly how complicated your app is. If it's too complicated, this type of document will show that pretty quickly.
My parents bought one of those go-video DVD players when they came out. After a few weeks it started skipping like crazy.
I told them to buy a Toshiba, and they haven't had problems in years.
The only one of my opticals that failed is a lite-on from a few years back. Everything else survives well, including an old Apple 300i 2x CD.
Quality components last. Commodity components are more of a crapshoot when it comes to longevity. But really, I would rather have spend less money and replace than buy a high-quality that lasts past its obsolesence (like the 300i).
I remember reading comments by someone on the original "eve" study that implied that the "Out of Africa" theory of human origin was one possible interpretation of the data. There were other interpretations that were as likely, but not consistent with the current dogma.
Well, you might want to wait a bit and see how it shakes out. Check the early adopter reports on macintouch.com and macfixit.com to see what issues people run into.
Unlike Windows, MacOS X upgrades tend to be pretty clean. If they go bad, though, they're catastrophic (FileVault, anyone?).
These days, I tend to back up, clean-install everything, drop all my documents back, and reinstall my 3rd-party apps. But archive & install does work pretty well (I did that on another one of my Macs). The only reason to clean install is the upgrade process seems to use more disk space than a clean install (old files?).
In the cases sited (whistleblower cases), the people involved were exposing violations of Federal law.
In the Think Secret case, the issue is whether a journalist (whatever definition you use) can refuse to provide the identity of an individual (or individuals) who provided trade secrets or confidential information about upcoming products.
Even the tobacco guys were more like whistleblowers, as they showed (or tried to show) that Congressional testimony by executives was demonstrably false.
The Think Secret case is nowhere near this, and Apple will most likely succeed. If Think Secret exposed a violation of law somewhere (death rays to be deployed in Cupertino, toxic waste, etc) then maybe they'd have a chance.
But as is, well, Think Secret is toast. They've gotta use better anonymizers, that's all.
One problem with Linux right now is there isn't a good site that lists all the features of the OS.
That, of course, is because the features depend on the packages you install.
However, think of this: if you're looking for a firewall, you have certain requirements in mind. How easy is it to find the capabilities of any of the linux built-in firewalls so you can see if it can handle the job?
It's hard. What you find are HOW-TOs. You have to plow through a ridiculous amount of stuff just to figure out if the built-in firewall can do what you need.
Commercial companies have SEs and marketeers that list and explain features, so potential customers don't have to become subject-matter experts just to understand the product's capabilties. There's no such thing on the linux side, as far as I can tell.
IF you're buying something, you'll tend to go with a company that's easy to work with. If it's hard to find pre-sales information, it'll be even harder to get help when you're in production.
Not everyone wants to know the ins and outs of ipfilter, iptables, or ipfw. They just want stuff that works, and is easy to set up and maintain.
One thing you get when you stop anthropromorphize evolution is you can stop asking "why" and "how."
Evolution is a process.
Just the other day in the NYT they were talking about how snake venom "evolved." But how did the poison gland get there in the first place? You can't have half a gland. There's no feedback mechanism for "better poison" or "worse poison." How can a poison "evolve" to better attack protein receptors in another animal's heart muscle?
The process is: changes occur. Some survive, some don't. Those that are profoundly negative cause the host to die. Everything else continues on, subject to chance.
How does qualitative change occur? Who knows? I don't think a qualitative change has occurred in a complex organism since humanity has been paying attention.
One interesting point about evolution is it violates the 2nd law of thermodynamics. Organisms should be getting simpler, not more complicated. Interesting.
What you're saying is: stuff I think is importand is journalism. Stuff I don't think is important isn't journalism.
Protections extend to anyone that publishes, in any written form. The quality of that content is irrelevant to whether that writer enjoys protection under the law.
TV shows exist as an advertising vehicle for TV stations. TV stations affiliate themselves with the networks because the network allows them access to shows, scheduling, branding, and marketing - all things you want when you're basically an advertising vehicle.
The TV shows themselves are somewhat independent of the TV Network that shows them - depending on the deal. It all depends on the deal.
An independently produced show (unlikely) could theoretically distribute itself any way it chose. There aren't a lot of options, but it could theoretically syndicate itself to independent stations. That's unlikely, because the draw would be somewhere near 0.
Today, well, it's unclear if providing downloadables would be a viable business, but I doubt it would conflict with the post-season DVD. The post-season DVDs have a lot of extras, and come in a nice box. For the general public, that's hard to beat.
Bandwidth costs alone would make downloadables a losing business. With Bittorrent you're piggybacking off of everyone else's bandwidth, but a real ("official") provider would have brutal bandwidth charges.
As a demonstration of Microsoft's continuing committment to the Media Center initiative, you will now be receiving free anti-virus and anti-spyware tools with your Media Center PC.
Microsoft Corporation. Bringing Technology to your Desktop, Laptop, and Living Room for over 20 years. Your Trusted Name in Technology.
Everyone on Earth who saw the original Star Wars is compelled by some unknown force to watch these god-awful movies.
Just think for a minute: the Republic was so feeble that Jar-Jar binks was allowed to be a representative in the Senate - and people listened to him! The Jedi were so clueless that they were funding the creation of a clone army - and didn't notice the expense for years!
Heck, the Jedi were so all-powerful that they were almost wiped out, and the last two were reduced to hiding out in a swamp (Yoda) and hiding out stalking a young boy (Obi-Wan).
Instead of their stream, just head on over to your favorite bittorrent site and download the 4-hour pilot (DivX). Then download all the other episodes you missed.
In this case, it really helps to be aware of the optimization basics: loop unrolling, cse, hoisting, etc. and the different addressing modes of your CPU.
Assembly really is the way to go on these. You can get away with a whole lot of stuff in assembly. For example, most opcodes set a bunch of condition codes when you do things, and that really isn't taken advantage of by the compiler.
One good thing if your optimizer sucks is to use the compiler as a front-end translator. Then you take the unoptimized output and optimize that.
Well, in Java this may speed things up. All instance variable references won't be cached locally. It's been a while since I checked this, but I believe that it's still true. Just something to think about if you're looping a few million times.
Sometimes it helps, sometimes it doesn't. The only way to really know what your compiler does is to look at the output of the compiler, and understand what all those switches do.
Now there are some things you can do to optimize your code while you're writing it, but a lot of that is heavily dependent on your platform, runtime, and environment. In general, you should write your code in a straightforward way, then write an optimized version of it later (if you determine it's necessary).
Of course, the best way to help your optimizer is to write things in the simplest manner possible.
Slashdot Mirror
One problem with removing SUID and GUID is it'll break management scripts.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that.
So much for that functionality. Instead, we'll get something worse: people writing binaries that SUID and execute any random shell script, like this:
runsuid --script=/usr/bin/my_script --user=root
Gee, thanks.
Why not get rid of the shell while you're at it? That command line is a security problem waiting to happen. And while you're at it, remove process invocation commands like exec. Those can be used to run executables, which could cause Bad Things to Happen.
What a freaking PITA. I mean, if there was a bug in SUID/GUID handling, fix it. Removing it is really drastic. What's next, removing "rm" because it could delete files?
If your product has a UI, then the design document should start by describing the UI and how all the features work.
If you don't have a UI, then start from the configuration file or command line switches, and do the same thing.
Then you're done. If you can't configure a feature, or can't trigger it from the UI, then it shouldn't exist...unless there are other interaction points.
If you have a network app, document the wire protocol, range of input values, and expected behaviors (of your app and its clients) and outputs.
If it's a distributed system, figure out the different states and document them.
It's actually a pretty simple, though tedious, process. Starting from the UI is a great place, because it shows you instantly how complicated your app is. If it's too complicated, this type of document will show that pretty quickly.
My parents bought one of those go-video DVD players when they came out. After a few weeks it started skipping like crazy.
I told them to buy a Toshiba, and they haven't had problems in years.
The only one of my opticals that failed is a lite-on from a few years back. Everything else survives well, including an old Apple 300i 2x CD.
Quality components last. Commodity components are more of a crapshoot when it comes to longevity. But really, I would rather have spend less money and replace than buy a high-quality that lasts past its obsolesence (like the 300i).
Sorry, had to do it
I remember reading comments by someone on the original "eve" study that implied that the "Out of Africa" theory of human origin was one possible interpretation of the data. There were other interpretations that were as likely, but not consistent with the current dogma.
Wonder if this study will clear up the OOA?
That's an interesting comment: is it illegal to publish classified documents?
I mean, if the government classifies a document, isn't that binding on government folks only?
Well, you might want to wait a bit and see how it shakes out. Check the early adopter reports on macintouch.com and macfixit.com to see what issues people run into.
Unlike Windows, MacOS X upgrades tend to be pretty clean. If they go bad, though, they're catastrophic (FileVault, anyone?).
These days, I tend to back up, clean-install everything, drop all my documents back, and reinstall my 3rd-party apps. But archive & install does work pretty well (I did that on another one of my Macs). The only reason to clean install is the upgrade process seems to use more disk space than a clean install (old files?).
ENjoy!
In the cases sited (whistleblower cases), the people involved were exposing violations of Federal law.
In the Think Secret case, the issue is whether a journalist (whatever definition you use) can refuse to provide the identity of an individual (or individuals) who provided trade secrets or confidential information about upcoming products.
Even the tobacco guys were more like whistleblowers, as they showed (or tried to show) that Congressional testimony by executives was demonstrably false.
The Think Secret case is nowhere near this, and Apple will most likely succeed. If Think Secret exposed a violation of law somewhere (death rays to be deployed in Cupertino, toxic waste, etc) then maybe they'd have a chance.
But as is, well, Think Secret is toast. They've gotta use better anonymizers, that's all.
Maybe the pre-cambrian die-off was caused by massive flatulence on the part of the multi-celled organisms at the time?
This is about as likely as any other theory, except for the question as to whether methane was a by-product of life at the time.
Of course, it's just as likely as "some neutron stars somewhere colliding."
One problem with Linux right now is there isn't a good site that lists all the features of the OS.
That, of course, is because the features depend on the packages you install.
However, think of this: if you're looking for a firewall, you have certain requirements in mind. How easy is it to find the capabilities of any of the linux built-in firewalls so you can see if it can handle the job?
It's hard. What you find are HOW-TOs. You have to plow through a ridiculous amount of stuff just to figure out if the built-in firewall can do what you need.
Commercial companies have SEs and marketeers that list and explain features, so potential customers don't have to become subject-matter experts just to understand the product's capabilties. There's no such thing on the linux side, as far as I can tell.
IF you're buying something, you'll tend to go with a company that's easy to work with. If it's hard to find pre-sales information, it'll be even harder to get help when you're in production.
Not everyone wants to know the ins and outs of ipfilter, iptables, or ipfw. They just want stuff that works, and is easy to set up and maintain.
One thing you get when you stop anthropromorphize evolution is you can stop asking "why" and "how."
Evolution is a process.
Just the other day in the NYT they were talking about how snake venom "evolved." But how did the poison gland get there in the first place? You can't have half a gland. There's no feedback mechanism for "better poison" or "worse poison." How can a poison "evolve" to better attack protein receptors in another animal's heart muscle?
The process is: changes occur. Some survive, some don't. Those that are profoundly negative cause the host to die. Everything else continues on, subject to chance.
How does qualitative change occur? Who knows? I don't think a qualitative change has occurred in a complex organism since humanity has been paying attention.
One interesting point about evolution is it violates the 2nd law of thermodynamics. Organisms should be getting simpler, not more complicated. Interesting.
I hope that wagon's got airbags, because the driver's gotta be drinking heavily during his job.
Maybe it's because the reporter didn't have phone numbers for the female scientists, so was unable to call them?
It could be bias, it could be the women were too busy to take the call, it could be that old Bob is a glory hound.
There's a blast from the past reference there, Bill!
Say hi to Steve Jarrett for me!
And don't get caught biking the wrong way around the lake!
In the US, the ISP could sue for damages, and there's a good chance the APB would settle for a large sum.
Can they do that in Sweden? Or are they just going to get a "so sorry, we'll be sure it doesn't happen again (until next time)?"
After they understand the game, you have to start layering it to give them more of an idea (if you can).
For example, you just figured out how to guess a number. Now you can take that and trigger a robot to move. How would you do that, etc etc.
It's all about deconstruction and reconstruction. You do have to avoid those two words, though.
What you're saying is: stuff I think is importand is journalism. Stuff I don't think is important isn't journalism.
Protections extend to anyone that publishes, in any written form. The quality of that content is irrelevant to whether that writer enjoys protection under the law.
The whole idea behind a mesh network is there is no single point of failure.
That does mean you have to design things so there isn't a single point of failure...unless you want a single point of failure, of course.
The spec just addresses the nuts and bolts of devices talking to each other. It doesn't take the place of an intelligent designer.
Just an FYI, WiMAX runs across both licensed and unlicensed bands.
TV shows exist as an advertising vehicle for TV stations. TV stations affiliate themselves with the networks because the network allows them access to shows, scheduling, branding, and marketing - all things you want when you're basically an advertising vehicle.
The TV shows themselves are somewhat independent of the TV Network that shows them - depending on the deal. It all depends on the deal.
An independently produced show (unlikely) could theoretically distribute itself any way it chose. There aren't a lot of options, but it could theoretically syndicate itself to independent stations. That's unlikely, because the draw would be somewhere near 0.
Today, well, it's unclear if providing downloadables would be a viable business, but I doubt it would conflict with the post-season DVD. The post-season DVDs have a lot of extras, and come in a nice box. For the general public, that's hard to beat.
Bandwidth costs alone would make downloadables a losing business. With Bittorrent you're piggybacking off of everyone else's bandwidth, but a real ("official") provider would have brutal bandwidth charges.
As a demonstration of Microsoft's continuing committment to the Media Center initiative, you will now be receiving free anti-virus and anti-spyware tools with your Media Center PC.
Microsoft Corporation. Bringing Technology to your Desktop, Laptop, and Living Room for over 20 years. Your Trusted Name in Technology.
They don't need trailers, really.
Everyone on Earth who saw the original Star Wars is compelled by some unknown force to watch these god-awful movies.
Just think for a minute: the Republic was so feeble that Jar-Jar binks was allowed to be a representative in the Senate - and people listened to him! The Jedi were so clueless that they were funding the creation of a clone army - and didn't notice the expense for years!
Heck, the Jedi were so all-powerful that they were almost wiped out, and the last two were reduced to hiding out in a swamp (Yoda) and hiding out stalking a young boy (Obi-Wan).
This is what the rebels were fighting for?
Yeah, it's worth it.
Instead of their stream, just head on over to your favorite bittorrent site and download the 4-hour pilot (DivX). Then download all the other episodes you missed.
In this case, it really helps to be aware of the optimization basics: loop unrolling, cse, hoisting, etc. and the different addressing modes of your CPU.
Assembly really is the way to go on these. You can get away with a whole lot of stuff in assembly. For example, most opcodes set a bunch of condition codes when you do things, and that really isn't taken advantage of by the compiler.
One good thing if your optimizer sucks is to use the compiler as a front-end translator. Then you take the unoptimized output and optimize that.
Well, in Java this may speed things up. All instance variable references won't be cached locally. It's been a while since I checked this, but I believe that it's still true. Just something to think about if you're looping a few million times.
Sometimes it helps, sometimes it doesn't. The only way to really know what your compiler does is to look at the output of the compiler, and understand what all those switches do.
Now there are some things you can do to optimize your code while you're writing it, but a lot of that is heavily dependent on your platform, runtime, and environment. In general, you should write your code in a straightforward way, then write an optimized version of it later (if you determine it's necessary).
Of course, the best way to help your optimizer is to write things in the simplest manner possible.