Maybe some enterprising scriptkiddie could automate this attack and hook it into a worm. Worm spreads over the internet affecting millions of IP addreses. Catalog companies are inundated with requests and overload the Postal Service. US government steps in and actually starts regulating junk mail.
Nah, probably wouldn't work... The virus would produce enough publicity that the Catalog companies would know about it and it would be in their interest to eliminate bogus mails from going out. Someone would reverse engineer the virus and use that information so that catalog companies could protect their online forms. Impact would be minimal.
Damn, I'd really like a way to stop junk mail though...
They look nice in a GUI file browser, but I hate typing them on the command line, it slows me down.
More seriously, someone needs to come up with a scheme whereby users can configure their own standards for filesystem layout and applications will transparently use it. This would eliminate all the arguments over the "right" way for a filesystem to be layed out.
All you need to do is setup a system-wide configuration file in well known place (it needs to be in/, since we can't depend on any directory structure, so my suggestion would be/layout.conf). You then need hooks in glibc so that applications can find their configuration files and libraries. You also need hooks in the installer so that applications will be properly installed.
This is easy to design, difficult to implement. You'd need to convert enough applications to use this scheme to get the ball rolling and get other developers to see the light and start writing their programs to be/layout.conf-aware. I keep on thinking I should convert a FreeBSD tree to use a scheme like this, but the tedious work involved in patching the tree would take more than what I've got available in free time.
Think about the payoffs though. You no longer need to choose your distribution based on what filesystem layout you like. And RPMs (or debs, or whatever) would become substantially more portable between different distributions. The distribution authors would merely 'suggest' a default layout. The end user would be free to override those defaults in the installer (or kickstart) and pick different layouts. If you wanted to build your system so that every single binary was in/app/progname/bin (even to the extreme of/app/ls/bin/ls) then you could -- and with the right libraries and databases of installed programs your PATH would transparently become a complete nightmare! Then you could fix that PATH nightmare by configuring/bin to contain symlinks to every single binary on your system. Whatever you want.
Programs can get used in unusual ways. If you happen to have a drawing application which is started up by your web-browser then a malicious piece of content on the web could hack into your account that way. Setuid programs may call external programs which don't normally run with elevated privs (sudo is a really common way of doing this).
There are two different ways of dealing with this -- either auditing your entire system for exploits assuming that any piece of code may be running with elevated privs at some point -- or by auding your system to reduce the amount of code which runs with elevated privs. I would argue that both approaches are necessary. As an OS vendor you should be taking the former approach since you want to give your customer the most flexible system that you can and dont want to limit them.
OpenBSD is actually doing the right thing there. I think there's a bit of arrogance on the part of other operating system vendors who would rather say "well you shouldn't be using that in an evironment with elevated privs" rather than fixing their issues.
define "the public" and "those who have the capacity to fix them".
I have the sources to the operating system that I prefer to run and all the apps that run on it. I am a unix system engineer of quite a few years experience now. I know how to program C with about 13 years of experience there. I believe very firmly that I am in the category of "those who have the capacity to fix them". I am not, however, in the inner circle of those who get early access to CERT security information.
Yes because in the hands of the right (or in this case wrong) person, they could certainly be used as a "weapons delivery system". They can reach altitudes high enough to distribute chemical or biological agents over a broader area than might otherwise be possible. They are (or at least have been) more inconspicuous than say a crop duster which has also come under scrutiny as a possible delivery method.
Actually, No. You aren't going to be able to get enough chemical, biological or radiological agents into a model rocket. You are going to have a difficult time dispersing them. Even after you disperse them, even the slightest wind will render the attack very ineffective.
Chemical, biological and radiological agents are very difficult to use for terror or even to weaponize for warfare. You typically need to drop tons of chemical weapons in an area to start killing people. You need to weaponsize biological agents and you need to keep them in sufficient concentration (if the wind blows them until they're too dilute, or if they fall to the ground they aren't going to kill anyone). Radiological weapons would probably be your best bet, but due to the cleanup effort that would follow them.
It would be much more effective to use chemical, biological or radiological attacks in a tunnel or other closed environment. Even there, the sarin attack in Tokyo shows how difficult it is to kill a lot of people in a closed space. I really doubt any terrorist would bother with using model rockets as a delivery vehicle -- it would just waste their valuable (to them) toxins.
I didn't say that IBM is opposed to TCPA. I'm saying that IBM is in favor of linux running on cheap commodity hardware. Where TCPA starts to interfere with linux running on cheap commodity hardware (if the RIAA/MPAA actually gets some traction) is where IBMs position on TCPA will get very interesting.
And I've tried to describe why TCPA is relevant to linux if hardware ever started to mandate trusted operating systems. If you don't understand that relationship, I don't know how I can help you.
And developing a trusted version of Linux would be easy in theory, all it takes is a RedHat or IBM to setup a single trusted source.
Palladium does have an application for content protection.
Palladium is all about certifying through a bootstrapping procedure that your turing machine is in an approved state. It certifies that your BIOS has not been tampered with, then it certifies that your O/S has not been tampered with, then it will go on to certify that your applications have not been tampered with. Then your applications will be able to certify to a remote entity that your computer is in a known state. That means that a remote content service can stream audio or video to you and know that at least for the digital part of the circuit you have not made any attacks on their DRM. A remote content provider will be able to feel certain that you haven't loaded a device driver which intercepts audio to the speakers and instead rips it to disk (for example).
Of course you could still be capturing the analog audio or VGA output of your sound/video card. I assume that what they would like to do there is have DRM chips in all computer speakers and monitors and in all television sets and go digital and encrypted all the way to those units. Then palladium could easily certify that you were using a DRM-enabled monitor or speakers to the remote content provider.
A bit scarier possibility is that they want to have all content watermarked and then force you to be inable to run your soundcard or videocard on a an O/S which doesn't have DRM enabled. Of course the only way this would work would be if it was legislated and if all sound and video cards were forced to be manufactured so that they would no longer work with non-DRM O/S. The music industry would really like this since it would start to close the loophole where anyone can figure out how to rip an mp3 and put it up and everyone can download it. They want it pretty badly. On the other side though, it would create a pretty interesting lawsuit (IANAL: Restraint of Trade?) by the companies (RedHat, IBM, Amazon, etc) who are invested heavily in Linux.
But as long as you can take an analog signal, rip it to mp3, share it with the world, and play it on a linux or freebsd box even it if is digitally watermarked, the RIAA will keep lobbying congress with schemes to try to make you stop doing that. They have three choices: to attack the creation of the mp3, to attack the file sharing and to attack the playback on the linux/freebsd box.
I've already outlined what they want to do to start attack the creation of mp3s and divx's using Palladium and having digitally encrypted signals to your speakers/monitor. However at some point it has to go to analog, so there needs to be an digital to analog converter in there somewhere. One thing that the RIAA has tried to get into law is putting DRM in all DAC/ADCs. This attempt got nowhere, and I expect that future attempts will get nowhere as well since the effect on the entire semiconductor industry would be huge.
The next attack is against file sharing, and here we see the issues that have been recently raised over vigilante hacking. They've managed to legally shut down networks like napster, but they seem to be stymied when it comes to decentralized networks like gnutella. They don't seem to be able to go after individual file sharers. They don't seem to be having enough success trying to disrupt file sharing networks. So they're looking for legal grounds to just hack in to people's machines and remove the mp3s. There could be some interesting escalating warfare in this area in the near future.
The third attack is against being able to play mp3s and divx's on machines running palladium-uncertified (and therefore modifiable) operating systems. I really see this as being the area most open to attack. The problem is that RedHat and IBM and Amazon will fight to keep linux running on cheap commodity hardware, but they don't care much about your ability to playback mp3s on linux. They could always arrive at a compromise which allowed them to run their servers on linux, but which denied you the ability to playback mp3s and divx's. One easy first step would be to legally mandate that sound cards would only work with palladium-enabled operating systems. Most companies like amazon wouldn't care since they don't put soundcards in any of their servers anyway. And the option could be left open for a RedHat or IBM to produce a palladium-certified linux operating system which would allow sound cards to work in a controlled DRM environment. I don't know what they would do with divx playback on video cards.
Anyway, the RIAA/MPAA want very badly to stop internet file sharing, and Palladium is definitely one way to try to do it. It will be interesting to see if Palladium will actually accomplish this goal and what abilities of consumers (and open source developers) will get compromised along the way...
I'm still only in Gondor. Every time I think I'm going to wake up in Mordor. When I was back in the Shire after my first tour it was worse. I'd wake up and I'd be nothing.
I'm here a week now. Waiting for a quest. Getting softer. Every minute I stay in this city I get weaker. Every minute Sauron squats in the tower he gets stronger.
Each time I look around, the Spires of Gondor move in a little closer.
Everyone gets everything he wants. I wanted a quest, and for my sins they gave me one. Brought it up to me like room service. It was a real choice quest and when it was over, I'd never want another. I was going to the worst place in the world, and I didn't even know it yet. Weeks away and over hundreds of miles of trails through blasted landscape like a main circuit cable plugged straight into Sauron. It was no accident that I got to be the caretaker of the Dark Lord Sauron's memory, any more than being back in Gondor was an accident.
--
Elrond: Your mission is to proceed down the Anduin River in an Elvish row boat. Pick up Sauron's path at the Falls of Rauros. When you find Mordor, infiltrate Sauron's borders by whatever means available and terminate the Dark Lord's Ring of Power.
Galadriel: Terminate the Dark Lord.
Elrond: He's out there operating with any decent restraint, totally beyond the pale of Maiar conduct. And he is still in the field commanding orcs.
Celeborn: Terminate the Dark Lord with extreme prejudice.
Galadriel: You understand Frodo that this mission does not exist, nor will it ever exist.
The very problem with C++ is that it tries to have multiple paradigms. You use OO when you want to have large teams of people composed of people with a variety of skillsets and when you're not as concerned about overall performance. OO is for the 100,000-1,000,000 line kind of programs.
For that kind of environment you want a language which is fully OO and lacks the flexibility of C++. You want garbage collection so that you don't have to waste time tracking down the memory leaks that your junior developers write. You want all functions to be virtual so that you don't have to waste time tracking down subtle errors there. What you're concerned about is Rapid Application Design which is something that Java was designed around and C++ was not.
You can probably make C++ work this way. You can get the bohm gc and compile with virtual functions forced on (-fall-virtual in g++) and adopt other style guidelines to make it work. But at that point you might as well be using Java, particularly since you're never going to get C++ to read as cleanly as Java. Also doing this work to get C++ to act like Java sort of negates why you're trying to use RAD in the first place.
Yes, I agree it makes sense to use the correct paradigm in the correct place, but I believe its generally better to use multiple languages to accomplish that. C++'s object-orientation is kind of an abortion. I can see how it might be good for scientific applications and computer games where you've got programming teams entirely composed of very smart people and you want OO and speed all in one package. For the rest of the world there is a much bigger issue than performance which is the ability to assemble a large team of people and rapidly produce a product that you can get to market faster than your competitors and with fewer bugs.
AFAIK, the admins never knew. They had spent much of my undergrad time trying to find SOMETHING I'd done, to punish me for, so if they'd known about this...
What is it with college system admins punishing undergrads for the admin's incompetence? I ran into the same kind of problem in college when the admins of my department decided to blame me for the fact that they got rooted every 6 months by the latest root-hole du jour. I did in fact hack one of their machines once, but I got the root prompt, typed 'exit' and sent a capture of the output to the admin of the box. This was back when I was incredibly naive and believe that this was "helping" the admin. After that was recieved so coldly I never did it again, but all I heard about was how they'd love to blame all their rooted boxes on me if they could only find solid evidence.
DESCRIPTION
The alloca() function allocates size bytes of space in the stack frame of
the caller. This temporary space is automatically freed on return.
RETURN VALUES
The alloca() function returns a pointer to the beginning of the allocated
space. If the allocation failed, a NULL pointer is returned.
SEE ALSO
brk(2), calloc(3), getpagesize(3), malloc(3), realloc(3)
BUGS
The alloca() function is machine dependent; its use is discouraged.
A) This is not open source you're talking about at all. You don't understand the term, obviously, or are abusing it to somehow seem relevant to Slashdot.
I wasn't aware that "news for nerds, stuff that matters" actually translated to "discuss open source only or fsck the hell off!"
I don't see how nerds with consulting companies that want to sign closed-source contracts is somehow off-topic for slashdot...
So reading the actual article, it sounds like what they found was an upper limit on the radius of the object. And given that upper limit, it is true that 3.7 million solar masses packed into an area that small will collapse really quickly into a black hole. I don't think the astronomers are claiming to have found the size of the object, just placed an upper boundary on its size.
No, physics doesn't stop at the edge, our understanding of physics breaks down at the edge. We don't know what happens because our physics deals in infinities that make no sense once you cross the event horizon. Physics still exists, it's just undefined to us.
You're close, although there's a glaring misunderstanding in this statement. At the Event Horizon there really isn't a singularity. For observers at large distances there is an infinity at the event horizon. For observers travelling through the event horizon there is no infinity.
I can't actually reproduce the mathematics offhand, but I've gone through this before in class. Once you've done it, its very obvious that the infinity at the event horizon is an artifact of your chosen co-ordinate system.
Now this is all important because physics is all local. The only coordinate system that matters is the local co-ordinate system. That's the major message which Einstein spent his whole life trying to get across.
So, don't get hung up on the Event Horizon.
At the same time, I can appreciate the fact that its just a theory. I still haven't seen anything which really conclusively proved that an event horizon exists. I think they've concluded that there needs to be a state of matter which is more compact than a neutron star, but that doesn't say anything about the existance of a neutron star. For all I think we know the old, old theory of a "Gravitationally Completely Collapsed Object" could still describe what they've observed.
The real evidence would come from stuff like gravitational wave observations of coalescing neutron stars or coalescing black holes. That should carry off information about the actual physics in that regeime and would provide a decent test of general relativity there.
And finally, the singularity at the center of a black hole really exists in every coordinate frame of reference. That infinity strongly suggests that there's physics which we don't know and that we need a theory of quantum gravity or whatever to explain what is really happening there.
Please mod down all the people who are currently at +5 claiming that the size of the object is really the event horizon, which is very large due to it being a supermassive black hole. This is a true statement, but it still doesn't explain the claimed size of the black hole in the article.
If you work out the schwartzchild radius of the sun using r=2GM/c^2 it comes out to around 3000 m. For the upper limit of 3.7 million solar masses that would mean that the black hole had a schwartzchild radius of around 1 x 10^10 m. This is about a factor of 14 larger than the radius of the sun which is 7 x 10^8 m.
This is no where near as large as the "volume of space around 3 times larger than the solar system" which is in the article. The poster of the article was also correct that the density was way too low. It is correct that supermassive black holes have large event horizons which are larger than the radii of typical stars like the sun. However, the average density inside of that event horizon is still denser than a neutron star.
I wish I had the 5 moderator points I had last week, I'd go to town on this story...
it isn't downtime that's the problem. we can do rolling upgrades so that we never lose any services. the problem is that you start to lose support for older versions of the O/S both in software and for hardware. eventually it becomes a pain to maintain old versions of the operating system, particularly when you'd like some of the newer features.
the problem is that it would be best to do those upgrades on your own schedule, rather than the "release early, release often" 6 month upgrade cycle.
Which is one major reason why I like FreeBSD better than any other open source distribution out there. They also have the ability to do this even though they don't have anyone paying them large quantities of money, or any large companies behind them.
The company that I work for has a business relationship with RedHat and pays RedHat an extremely large flat-fee every year (take the average IT salary and multiply by approximately a factor of 10). So yes, I'm bitching about software that we pay for, not software which is free. And in the open source model we were *supposed* to be able to get all the features and service that we got out of commerical Unixes, particularly if we paid for the service. That doesn't seem to be happening.
And there's no where else to go to get a decent release cycle other than Sun or another commercial unix vendor. If open source wants that to be the answer that they give, that's fine for me, I'll start trying to set management expectations to avoid open source.
I admin 850 linux boxes, and as far as I am concerned "release early, release often (and provide no support for older versions)" is open source's major flaw. Developers doing it for fun don't want to support old versions. They're lazy. This laziness has been turned around into some kind of virtue by the open source movement.
What open source needs is a company which provides an 18 month upgrade cycle and supports three concurrent versions. This is exactly what Sun provides with Solaris, and is something that system admins really badly need. And its not just the upgrading issue. You also lose time on the front end of this release cycle because it takes a long time for vendors to certify their software for the new release of the operating system. RedHat is starting to ge some kind of clue about this and is switching to an 18 month release cycle with their advanced server product. They still put on this godawfully stupid dog and pony show though about they'll come in and (for a price) help to upgrade all you machines every time they release a new version. This is entirely unacceptable and waste of resource and a waste of money spent on RedHat. It is basically RedHat trying to turn their laziness into a business model.
And please don't talk about how you've got a couple of scripts whipped together to make it easy to manage 10 openbsd boxes. I'm on a team that manages *850* open source boxes. Whatever you suggest doing simply doesn't scale well enough to deal with doing 850 upgrades every 6-12 months. An upgrade will take everyone on my team offline for at least a month, and we can't afford to be doing that all the time. Also, the next upgrade we're doing is from RH6.2 to RH7.2. We haven't had the time yet to certify all our software for RH7.3 or RH8.0 so we're actually going to be starting out behind once again... This is how system management works at very large sites though.
RSA was a brilliant invention deserving of a software patent if anything was. It was a true invention, and now that the patent has expired, it's in the public domain, for the benefit of all. This is the sort of innovation that patents exist to encourage, and the only justification for them.
The RSA patent is actually my favorite example of a patent which hurt the computer industry for a number of years before it finally expired. We really needed RSA to be unencumbered in the early 90s when the internet was just taking off. If we hadn't had crypto patents back then maybe we'd actually have something like DNSSEC now.
Personally I think there needs to be a moritorium on software patents in order to allow software to rapidly develop. Patents do not really encourage development. I have every expectation that R, S and A would have developed their crypto system even if they couldn't have patented it. Similarly, I'm sure that Amazon would have produced one-click even if it wasn't patentable.
I don't see where elminating software patents will do any harm. It will, however, mean that you can't just invent one critical piece of software or algorithm and have a consistant gravy train for 20 years. It means that to get a consistant source of cash you have to innovate year over year, which apparently scares the crap out of a lot of powerful people.
What really fucks with my head is that a billion years ago venus was resurfaced. The entire crust of the planet melted, resetting the entire geological history of the crust.
It would have sucked to have been living on venus when that happened...
Re:Linux for desktop, *BSD for servers?
on
FreeBSD 4.6
·
· Score: 3, Interesting
More experienced administrators: do you support this kind of dualism?
I'd support it if the ISVs did.
I'm 1 of 8 admins that take care of appx 600 Linux boxes (projected to grow to 1,000 Linux boxes by the end of the year). We run software by BEA and Tibco on our machines (and probably other packages I'm not as familiar with, but those are the major two). We're interested in Oracle on top of Linux.
Unfortunately, there's no ISV support for FreeBSD and while I'd *LOVE* to choose FreeBSD over Linux I can't do it for business reasons. Unfortunately this also leads to choose me to avoid FreeBSD even for ISV-free machines at work. The pool of System Engineers that we've got is more familiar with Linux than FreeBSD, and there's no way to guarantee than an ISV product won't be needed on any given machine in the future.
And unfortunately when I'm talking about Linux ISV support I'm necessarily talking about RedHat ISV support. I really wish that either SuSE or FreeBSD would be supported by ISVs. RedHat is just flatly the worst Unix distribution in the world. They still insist on release kernels that have VMs which are substantially more fucked up than the vanilla one. Isn't it about time to simply recognize that the only guy in the Linux community who understands how to write a stable VM works for SuSE and move on?
Unfortunately, what I care about most in a Unix OS is (in order):
ISV support
12-18 month release cycle
Three supported versions of distro (yes, that means you have to support a distribution for 3-5 years)
Hardware product testing matrix and good QA
I can get this out of Solaris. The only Linux distribution which comes close to this is RedHat and they really need to work on the third point and don't even come close to the fourth point (Intel hardware makes testing matrices difficult...)
And I'd like to emphasize how important that third point is. With 1,000 machines and 8 people we can't handle upgrading all those machines every 6-9 months. "Release Early, Release Often" is an open source lie.
If you're just building basic infrastructure, I'd agree that FreeBSD is the way to go over Linux. The one caveat to that is if you're using heavy SMP machines like 6-way boxes (like we do). Then you need to wait for FreeBSD 5.x for the SMP support (and every indication is that it will cream Linux's SMP support after it gets stabilized).
This doesn't go anywhere near far enough
on
Is RPM Doomed?
·
· Score: 2
The executive summary is that there needs to be a better designed tool in between the software developer of the package and the system admin who installs it. I would like to have the flexibility to setup a policy on my machine as to weither or not I'm using/usr/local/bin or/usr/bin or/packages/whatever/bin, etc. And then have the installer configure the package correctly to install it however i'd like.
One thing this would necessitate is making the installer be much less flexible to the developer than RPMs. The problem with RPMs is that they're way too flexible for the developer of the package. There needs to be a simple, inflexible API or else you're going to have a mess.
I titled it "why unix needs a registry?" just to throw some gasoline on the fire... Read it and see what I really mean (unix needs a centrally-accessable database of metadata about installed programs...)
You don't understand the issue. The issue is that SCSI drives don't lie about write completion while IDE drives do. That means that even with a journaled filesystem your data integrity can be compromised by using IDE drives, but not with SCSI drives. It has nothing to do with the crappiness or otherwise of anyone's IDE or SCSI drivers. This issue would exist in a world with perfect OS drivers and perfect journaling and/or softupdate filesystems.
Granted, there's a tradeoff here. How likely are you to get bitten by this IDE issue? Remember that you have to lose power to the drive at the exact same time that you're doing at least two virutally simultaneous transactions to the disk which get reordered in the write buffer. At home its probably worth the risk in exchange for the cheap storage. At some point though you start dealing with workloads which increase the risk and data becomes valuable enough to you that you're going to need to start using SCSI drives for the reliability.
No, the GNU manpage says that it should not be used in programs that you expect to be easily portable. That is a warning to the programmer that if they use sendfile() that they will likely need to code for multiple different APIs, and will need to use tools like GNU autoconf to work around differences. That does not mean that sendfile() "should not be used."
In fact, apache 2.0 now does exactly this -- determines the version of sendfile() on your system and implements the appropriate code to use it.
Slashdot: Bored at work? Come explain elementary coding practices to 15 year old hax0rs!
Slashdot Mirror
Nah, probably wouldn't work... The virus would produce enough publicity that the Catalog companies would know about it and it would be in their interest to eliminate bogus mails from going out. Someone would reverse engineer the virus and use that information so that catalog companies could protect their online forms.
Impact would be minimal.
Damn, I'd really like a way to stop junk mail though...
More seriously, someone needs to come up with a scheme whereby users can configure their own standards for filesystem layout and applications will transparently use it. This would eliminate all the arguments over the "right" way for a filesystem to be layed out.
All you need to do is setup a system-wide configuration file in well known place (it needs to be in /, since we can't depend on any directory structure, so my suggestion would be /layout.conf). You then need hooks in glibc so that applications can find their configuration files and libraries. You also need hooks in the installer so that applications will be properly installed.
This is easy to design, difficult to implement. You'd need to convert enough applications to use this scheme to get the ball rolling and get other developers to see the light and start writing their programs to be /layout.conf-aware. I keep on thinking I should convert a FreeBSD tree to use a scheme like this, but the tedious work involved in patching the tree would take more than what I've got available in free time.
Think about the payoffs though. You no longer need to choose your distribution based on what filesystem layout you like. And RPMs (or debs, or whatever) would become substantially more portable between different distributions. The distribution authors would merely 'suggest' a default layout. The end user would be free to override those defaults in the installer (or kickstart) and pick different layouts. If you wanted to build your system so that every single binary was in /app/progname/bin (even to the extreme of /app/ls/bin/ls) then you could -- and with the right libraries and databases of installed programs your PATH would transparently become a complete nightmare! Then you could fix that PATH nightmare by configuring /bin to contain symlinks to every single binary on your system. Whatever you want.
There are two different ways of dealing with this -- either auditing your entire system for exploits assuming that any piece of code may be running with elevated privs at some point -- or by auding your system to reduce the amount of code which runs with elevated privs. I would argue that both approaches are necessary. As an OS vendor you should be taking the former approach since you want to give your customer the most flexible system that you can and dont want to limit them.
OpenBSD is actually doing the right thing there. I think there's a bit of arrogance on the part of other operating system vendors who would rather say "well you shouldn't be using that in an evironment with elevated privs" rather than fixing their issues.
define "the public" and "those who have the capacity to fix them".
I have the sources to the operating system that I prefer to run and all the apps that run on it. I am a unix system engineer of quite a few years experience now. I know how to program C with about 13 years of experience there. I believe very firmly that I am in the category of "those who have the capacity to fix them". I am not, however, in the inner circle of those who get early access to CERT security information.
Actually, No. You aren't going to be able to get enough chemical, biological or radiological agents into a model rocket. You are going to have a difficult time dispersing them. Even after you disperse them, even the slightest wind will render the attack very ineffective.
Chemical, biological and radiological agents are very difficult to use for terror or even to weaponize for warfare. You typically need to drop tons of chemical weapons in an area to start killing people. You need to weaponsize biological agents and you need to keep them in sufficient concentration (if the wind blows them until they're too dilute, or if they fall to the ground they aren't going to kill anyone). Radiological weapons would probably be your best bet, but due to the cleanup effort that would follow them.
It would be much more effective to use chemical, biological or radiological attacks in a tunnel or other closed environment. Even there, the sarin attack in Tokyo shows how difficult it is to kill a lot of people in a closed space. I really doubt any terrorist would bother with using model rockets as a delivery vehicle -- it would just waste their valuable (to them) toxins.
I didn't say that IBM is opposed to TCPA. I'm saying that IBM is in favor of linux running on cheap commodity hardware. Where TCPA starts to interfere with linux running on cheap commodity hardware (if the RIAA/MPAA actually gets some traction) is where IBMs position on TCPA will get very interesting.
And I've tried to describe why TCPA is relevant to linux if hardware ever started to mandate trusted operating systems. If you don't understand that relationship, I don't know how I can help you.
And developing a trusted version of Linux would be easy in theory, all it takes is a RedHat or IBM to setup a single trusted source.
Palladium does have an application for content protection.
Palladium is all about certifying through a bootstrapping procedure that your turing machine is in an approved state. It certifies that your BIOS has not been tampered with, then it certifies that your O/S has not been tampered with, then it will go on to certify that your applications have not been tampered with. Then your applications will be able to certify to a remote entity that your computer is in a known state. That means that a remote content service can stream audio or video to you and know that at least for the digital part of the circuit you have not made any attacks on their DRM. A remote content provider will be able to feel certain that you haven't loaded a device driver which intercepts audio to the speakers and instead rips it to disk (for example).
Of course you could still be capturing the analog audio or VGA output of your sound/video card. I assume that what they would like to do there is have DRM chips in all computer speakers and monitors and in all television sets and go digital and encrypted all the way to those units. Then palladium could easily certify that you were using a DRM-enabled monitor or speakers to the remote content provider.
A bit scarier possibility is that they want to have all content watermarked and then force you to be inable to run your soundcard or videocard on a an O/S which doesn't have DRM enabled. Of course the only way this would work would be if it was legislated and if all sound and video cards were forced to be manufactured so that they would no longer work with non-DRM O/S. The music industry would really like this since it would start to close the loophole where anyone can figure out how to rip an mp3 and put it up and everyone can download it. They want it pretty badly. On the other side though, it would create a pretty interesting lawsuit (IANAL: Restraint of Trade?) by the companies (RedHat, IBM, Amazon, etc) who are invested heavily in Linux.
But as long as you can take an analog signal, rip it to mp3, share it with the world, and play it on a linux or freebsd box even it if is digitally watermarked, the RIAA will keep lobbying congress with schemes to try to make you stop doing that.
They have three choices: to attack the creation of the mp3, to attack the file sharing and to attack the playback on the linux/freebsd box.
I've already outlined what they want to do to start attack the creation of mp3s and divx's using Palladium and having digitally encrypted signals to your speakers/monitor. However at some point it has to go to analog, so there needs to be an digital to analog converter in there somewhere. One thing that the RIAA has tried to get into law is putting DRM in all DAC/ADCs. This attempt got nowhere, and I expect that future attempts will get nowhere as well since the effect on the entire semiconductor industry would be huge.
The next attack is against file sharing, and here we see the issues that have been recently raised over vigilante hacking. They've managed to legally shut down networks like napster, but they seem to be stymied when it comes to decentralized networks like gnutella. They don't seem to be able to go after individual file sharers. They don't seem to be having enough success trying to disrupt file sharing networks. So they're looking for legal grounds to just hack in to people's machines and remove the mp3s. There could be some interesting escalating warfare in this area in the near future.
The third attack is against being able to play mp3s and divx's on machines running palladium-uncertified (and therefore modifiable) operating systems. I really see this as being the area most open to attack. The problem is that RedHat and IBM and Amazon will fight to keep linux running on cheap commodity hardware, but they don't care much about your ability to playback mp3s on linux. They could always arrive at a compromise which allowed them to run their servers on linux, but which denied you the ability to playback mp3s and divx's. One easy first step would be to legally mandate that sound cards would only work with palladium-enabled operating systems. Most companies like amazon wouldn't care since they don't put soundcards in any of their servers anyway. And the option could be left open for a RedHat or IBM to produce a palladium-certified linux operating system which would allow sound cards to work in a controlled DRM environment. I don't know what they would do with divx playback on video cards.
Anyway, the RIAA/MPAA want very badly to stop internet file sharing, and Palladium is definitely one way to try to do it. It will be interesting to see if Palladium will actually accomplish this goal and what abilities of consumers (and open source developers) will get compromised along the way...
Gondor... shit.
I'm still only in Gondor. Every time I think I'm going to wake up
in Mordor. When I was back in the Shire after my first tour it was worse.
I'd wake up and I'd be nothing.
I'm here a week now. Waiting for a quest. Getting softer. Every
minute I stay in this city I get weaker. Every minute Sauron squats in the
tower he gets stronger.
Each time I look around, the Spires of Gondor move in a little closer.
Everyone gets everything he wants. I wanted a quest, and for my sins
they gave me one. Brought it up to me like room service. It was a real
choice quest and when it was over, I'd never want another. I was going to
the worst place in the world, and I didn't even know it yet. Weeks away
and over hundreds of miles of trails through blasted landscape like
a main circuit cable plugged straight into Sauron. It was no accident
that I got to be the caretaker of the Dark Lord Sauron's memory, any more
than being back in Gondor was an accident.
--
Elrond: Your mission is to proceed down the Anduin River in an Elvish
row boat. Pick up Sauron's path at the Falls of Rauros. When you find
Mordor, infiltrate Sauron's borders by whatever means available and
terminate the Dark Lord's Ring of Power.
Galadriel: Terminate the Dark Lord.
Elrond: He's out there operating with any decent restraint, totally beyond
the pale of Maiar conduct. And he is still in the field commanding orcs.
Celeborn: Terminate the Dark Lord with extreme prejudice.
Galadriel: You understand Frodo that this mission does not exist, nor will
it ever exist.
The very problem with C++ is that it tries to have multiple paradigms. You use OO when you want to have large teams of people composed of people with a variety of skillsets and when you're not as concerned about overall performance. OO is for the 100,000-1,000,000 line kind of programs.
For that kind of environment you want a language which is fully OO and lacks the flexibility of C++. You want garbage collection so that you don't have to waste time tracking down the memory leaks that your junior developers write. You want all functions to be virtual so that you don't have to waste time tracking down subtle errors there. What you're concerned about is Rapid Application Design which is something that Java was designed around and C++ was not.
You can probably make C++ work this way. You can get the bohm gc and compile with virtual functions forced on (-fall-virtual in g++) and adopt other style guidelines to make it work. But at that point you might as well be using Java, particularly since you're never going to get C++ to read as cleanly as Java. Also doing this work to get C++ to act like Java sort of negates why you're trying to use RAD in the first place.
Yes, I agree it makes sense to use the correct paradigm in the correct place, but I believe its generally better to use multiple languages to accomplish that. C++'s object-orientation is kind of an abortion. I can see how it might be good for scientific applications and computer games where you've got programming teams entirely composed of very smart people and you want OO and speed all in one package. For the rest of the world there is a much bigger issue than performance which is the ability to assemble a large team of people and rapidly produce a product that you can get to market faster than your competitors and with fewer bugs.
What is it with college system admins punishing undergrads for the admin's incompetence? I ran into the same kind of problem in college when the admins of my department decided to blame me for the fact that they got rooted every 6 months by the latest root-hole du jour. I did in fact hack one of their machines once, but I got the root prompt, typed 'exit' and sent a capture of the output to the admin of the box. This was back when I was incredibly naive and believe that this was "helping" the admin. After that was recieved so coldly I never did it again, but all I heard about was how they'd love to blame all their rooted boxes on me if they could only find solid evidence.
Pricks.
From the FreeBSD manpage:
ALLOCA(3) FreeBSD Library Functions Manual ALLOCA(3)
NAME
alloca - memory allocator
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <stdlib.h>
void *
alloca(size_t size);
DESCRIPTION
The alloca() function allocates size bytes of space in the stack frame of
the caller. This temporary space is automatically freed on return.
RETURN VALUES
The alloca() function returns a pointer to the beginning of the allocated
space. If the allocation failed, a NULL pointer is returned.
SEE ALSO
brk(2), calloc(3), getpagesize(3), malloc(3), realloc(3)
BUGS
The alloca() function is machine dependent; its use is discouraged.
FreeBSD 5.0 June 4, 1993 FreeBSD 5.0
I wasn't aware that "news for nerds, stuff that matters" actually translated to "discuss open source only or fsck the hell off!"
I don't see how nerds with consulting companies that want to sign closed-source contracts is somehow off-topic for slashdot...
So reading the actual article, it sounds like what they found was an upper limit on the radius of the object. And given that upper limit, it is true that 3.7 million solar masses packed into an area that small will collapse really quickly into a black hole. I don't think the astronomers are claiming to have found the size of the object, just placed an upper boundary on its size.
You're close, although there's a glaring misunderstanding in this statement. At the Event Horizon there really isn't a singularity. For observers at large distances there is an infinity at the event horizon. For observers travelling through the event horizon there is no infinity.
I can't actually reproduce the mathematics offhand, but I've gone through this before in class. Once you've done it, its very obvious that the infinity at the event horizon is an artifact of your chosen co-ordinate system.
Now this is all important because physics is all local. The only coordinate system that matters is the local co-ordinate system. That's the major message which Einstein spent his whole life trying to get across.
So, don't get hung up on the Event Horizon.
At the same time, I can appreciate the fact that its just a theory. I still haven't seen anything which really conclusively proved that an event horizon exists. I think they've concluded that there needs to be a state of matter which is more compact than a neutron star, but that doesn't say anything about the existance of a neutron star. For all I think we know the old, old theory of a "Gravitationally Completely Collapsed Object" could still describe what they've observed.
The real evidence would come from stuff like gravitational wave observations of coalescing neutron stars or coalescing black holes. That should carry off information about the actual physics in that regeime and would provide a decent test of general relativity there.
And finally, the singularity at the center of a black hole really exists in every coordinate frame of reference. That infinity strongly suggests that there's physics which we don't know and that we need a theory of quantum gravity or whatever to explain what is really happening there.
Please mod down all the people who are currently at +5 claiming that the size of the object is really the event horizon, which is very large due to it being a supermassive black hole. This is a true statement, but it still doesn't explain the claimed size of the black hole in the article.
If you work out the schwartzchild radius of the sun using r=2GM/c^2 it comes out to around 3000 m. For the upper limit of 3.7 million solar masses that would mean that the black hole had a schwartzchild radius of around 1 x 10^10 m. This is about a factor of 14 larger than the radius of the sun which is 7 x 10^8 m.
This is no where near as large as the "volume of space around 3 times larger than the solar system" which is in the article. The poster of the article was also correct that the density was way too low. It is correct that supermassive black holes have large event horizons which are larger than the radii of typical stars like the sun. However, the average density inside of that event horizon is still denser than a neutron star.
I wish I had the 5 moderator points I had last week, I'd go to town on this story...
it isn't downtime that's the problem. we can do rolling upgrades so that we never lose any services. the problem is that you start to lose support for older versions of the O/S both in software and for hardware. eventually it becomes a pain to maintain old versions of the operating system, particularly when you'd like some of the newer features.
the problem is that it would be best to do those upgrades on your own schedule, rather than the "release early, release often" 6 month upgrade cycle.
Which is one major reason why I like FreeBSD better than any other open source distribution out there. They also have the ability to do this even though they don't have anyone paying them large quantities of money, or any large companies behind them.
The company that I work for has a business relationship with RedHat and pays RedHat an extremely large flat-fee every year (take the average IT salary and multiply by approximately a factor of 10). So yes, I'm bitching about software that we pay for, not software which is free. And in the open source model we were *supposed* to be able to get all the features and service that we got out of commerical Unixes, particularly if we paid for the service. That doesn't seem to be happening.
And there's no where else to go to get a decent release cycle other than Sun or another commercial unix vendor. If open source wants that to be the answer that they give, that's fine for me, I'll start trying to set management expectations to avoid open source.
I admin 850 linux boxes, and as far as I am concerned "release early, release often (and provide no support for older versions)" is open source's major flaw. Developers doing it for fun don't want to support old versions. They're lazy. This laziness has been turned around into some kind of virtue by the open source movement.
What open source needs is a company which provides an 18 month upgrade cycle and supports three concurrent versions. This is exactly what Sun provides with Solaris, and is something that system admins really badly need. And its not just the upgrading issue. You also lose time on the front end of this release cycle because it takes a long time for vendors to certify their software for the new release of the operating system. RedHat is starting to ge some kind of clue about this and is switching to an 18 month release cycle with their advanced server product. They still put on this godawfully stupid dog and pony show though about they'll come in and (for a price) help to upgrade all you machines every time they release a new version. This is entirely unacceptable and waste of resource and a waste of money spent on RedHat. It is basically RedHat trying to turn their laziness into a business model.
And please don't talk about how you've got a couple of scripts whipped together to make it easy to manage 10 openbsd boxes. I'm on a team that manages *850* open source boxes. Whatever you suggest doing simply doesn't scale well enough to deal with doing 850 upgrades every 6-12 months. An upgrade will take everyone on my team offline for at least a month, and we can't afford to be doing that all the time. Also, the next upgrade we're doing is from RH6.2 to RH7.2. We haven't had the time yet to certify all our software for RH7.3 or RH8.0 so we're actually going to be starting out behind once again... This is how system management works at very large sites though.
RSA was a brilliant invention deserving of a software patent if anything was. It was a true invention, and now that the patent has expired, it's in the public domain, for the benefit of all. This is the sort of innovation that patents exist to encourage, and the only justification for them.
The RSA patent is actually my favorite example of a patent which hurt the computer industry for a number of years before it finally expired. We really needed RSA to be unencumbered in the early 90s when the internet was just taking off. If we hadn't had crypto patents back then maybe we'd actually have something like DNSSEC now.
Personally I think there needs to be a moritorium on software patents in order to allow software to rapidly develop. Patents do not really encourage development. I have every expectation that R, S and A would have developed their crypto system even if they couldn't have patented it. Similarly, I'm sure that Amazon would have produced one-click even if it wasn't patentable.
I don't see where elminating software patents will do any harm. It will, however, mean that you can't just invent one critical piece of software or algorithm and have a consistant gravy train for 20 years. It means that to get a consistant source of cash you have to innovate year over year, which apparently scares the crap out of a lot of powerful people.
What really fucks with my head is that a billion years ago venus was resurfaced. The entire crust of the planet melted, resetting the entire geological history of the crust.
It would have sucked to have been living on venus when that happened...
I'd support it if the ISVs did.
I'm 1 of 8 admins that take care of appx 600 Linux boxes (projected to grow to 1,000 Linux boxes by the end of the year). We run software by BEA and Tibco on our machines (and probably other packages I'm not as familiar with, but those are the major two). We're interested in Oracle on top of Linux.
Unfortunately, there's no ISV support for FreeBSD and while I'd *LOVE* to choose FreeBSD over Linux I can't do it for business reasons. Unfortunately this also leads to choose me to avoid FreeBSD even for ISV-free machines at work. The pool of System Engineers that we've got is more familiar with Linux than FreeBSD, and there's no way to guarantee than an ISV product won't be needed on any given machine in the future.
And unfortunately when I'm talking about Linux ISV support I'm necessarily talking about RedHat ISV support. I really wish that either SuSE or FreeBSD would be supported by ISVs. RedHat is just flatly the worst Unix distribution in the world. They still insist on release kernels that have VMs which are substantially more fucked up than the vanilla one. Isn't it about time to simply recognize that the only guy in the Linux community who understands how to write a stable VM works for SuSE and move on?
Unfortunately, what I care about most in a Unix OS is (in order):
I can get this out of Solaris. The only Linux distribution which comes close to this is RedHat and they really need to work on the third point and don't even come close to the fourth point (Intel hardware makes testing matrices difficult...)
And I'd like to emphasize how important that third point is. With 1,000 machines and 8 people we can't handle upgrading all those machines every 6-9 months. "Release Early, Release Often" is an open source lie.
If you're just building basic infrastructure, I'd agree that FreeBSD is the way to go over Linux. The one caveat to that is if you're using heavy SMP machines like 6-way boxes (like we do). Then you need to wait for FreeBSD 5.x for the SMP support (and every indication is that it will cream Linux's SMP support after it gets stabilized).
The executive summary is that there needs to be a better designed tool in between the software developer of the package and the system admin who installs it. I would like to have the flexibility to setup a policy on my machine as to weither or not I'm using /usr/local/bin or /usr/bin or /packages/whatever/bin, etc. And then have the installer configure the package correctly to install it however i'd like.
One thing this would necessitate is making the installer be much less flexible to the developer than RPMs. The problem with RPMs is that they're way too flexible for the developer of the package. There needs to be a simple, inflexible API or else you're going to have a mess.
I titled it "why unix needs a registry?" just to throw some gasoline on the fire... Read it and see what I really mean (unix needs a centrally-accessable database of metadata about installed programs...)
Granted, there's a tradeoff here. How likely are you to get bitten by this IDE issue? Remember that you have to lose power to the drive at the exact same time that you're doing at least two virutally simultaneous transactions to the disk which get reordered in the write buffer. At home its probably worth the risk in exchange for the cheap storage. At some point though you start dealing with workloads which increase the risk and data becomes valuable enough to you that you're going to need to start using SCSI drives for the reliability.
In fact, apache 2.0 now does exactly this -- determines the version of sendfile() on your system and implements the appropriate code to use it.
Slashdot: Bored at work? Come explain elementary coding practices to 15 year old hax0rs!