As I understand it, they got that license pretty easily.
Lucas really wanted Lego to make Star Wars toys, but Lego had never done a tie-in before, so they didn't ask. So when Lego turned around and approached Lucas, it was pretty easy to get.
Some of the Star Wars Lego sets look interesting, like the AT-AT walker, but most are just a bunch of annoying custom pieces, from what I can see in the catalog. That's not appealing.
This is the perfect explanation of why compiling for yourself is generally a mistake.
Use a packaged version of things whenever possible. The package maintainers should have diagnosed and documented the critical incompatibilities (such as those listed above) and you don't have to deal with them.
Assuming you run everything at the default priority (0), the only thing you'll notice is that when you do use the gui, it will be slightly more responsive, due to your cpu-bound application being automatically given a lower priority.
In other words, you probably won't notice any change in behavior.
Preemption, as you describe it, has been there in every Linux kernel.
Preemption, as Linus referred to it in the release announcement, is Kernel preemption.
I.e, the kernel itself can be preempted. This has improved consistency for things such as xmms.
The problems you complain about are more likely the result of the new scheduler. Tell me, what nice level does X run at on your system? If it's -10, that's why your responsiveness sucks. Stop X from being reniced to -10 from 0 and you'll find that everything performs much smoother. The new scheduler does a much better job of actually respecting priorities, and as such doesn't need adjustements such as "nice" for everyday things such as running an X server.
If I say something is unclear, generally, I mean "It is unclear to me." I believe that's true of, oh, everyone, when they say that something is unclear.
So, I feel obliged to ponder: How do YOU disagree with my opinion that something is unclear?
Especially when I'm interviewing you saying, in essence, "What the heck is this about?"
True - and I wasn't really attempting to imply otherwise.
Maybe a better way to describe what I mean - a Blaster equivalent would have more trouble affecting the mail server, in a chroot-protected environment.
Luckily, the fixes are usually small enough that they don't impact anyone's configuration. (i.e, it was a bug that could only be triggered when someone was trying to break the system), or, the implications are clearly spelled out during the download process.
Of course, if you're installing 0-day security patches direct from mailing lists and recompiling yourself, you should have a good grasp as to what the patch is doing. If you don't, stick to the packaged versions that DO have review and include warnings telling you what they will be breaking.
My watch is a 250 meg flash device with a USB cable attached to it.
The odds of someone noticing it is extremely low.
Heck, when I worked at Chrysler, I wasn't searched, ever. (Worked there for a year.)
Most places can't pull off the security required to prevent internal leaks without making the workplace way too uncomfortable for the honest employees - which is generally a majority of them.
Debian (well, apt really) has a "Package Priority" system, that lets you selectively pick distributions, versions, etc, of packages to install.
The whole explanation gets complicated - but I have a machine at work that has Perl 5.6.1 installed, but the rest of the distribution comes from either Debian/testing or Debian/unstable, where Perl 5.8.1 is standard. (I have binary compatibility problems that require me to continue doing development against Perl 5.6.1)
Is that easy to do in Gentoo? It seems that a keyword based system would be a bit... limiting in that respect.
(Keep something in mind - most of computing revolves around, "is it good enough?" and not, "This is the best." Gentoo may be neat, but Debian is good enough for me, and the benefits that Gentoo may or may not provide don't seem big enough to make up for the time spent compiling everything, even in a setup where I could use distcc across somewhere around 10 machines.)
As I understand it, they got that license pretty easily.
Lucas really wanted Lego to make Star Wars toys, but Lego had never done a tie-in before, so they didn't ask. So when Lego turned around and approached Lucas, it was pretty easy to get.
Some of the Star Wars Lego sets look interesting, like the AT-AT walker, but most are just a bunch of annoying custom pieces, from what I can see in the catalog. That's not appealing.
Caldera was the company that purchased stuff from Novell.
Caldera then purchased the Unix business from Old SCO, now known as Tarantella.
Later Caldera changed it's name to "SCO" (this time not being an acronym)
See, that's why modern hosting facilities (or at least, forward thinking ones) don't run cable through the floor.
The floor is for cooling, environment control, etc. Fixed stuff.
You run cables overhead in raceways, where it has to be visible to everyone.
Visible problems get fixed. Hidden ones don't.
So the lesson is, force the likely problems to be visible, so that everyone has incentive to fix them.
In college I managed to stay connected to dialup for 3 months.
:)
That was a nice nice time period.
Umm, maybe *that* is because SCO is the company that was formerly known as Caldera?
Nah, that'd be too logical.
This is the perfect explanation of why compiling for yourself is generally a mistake.
Use a packaged version of things whenever possible. The package maintainers should have diagnosed and documented the critical incompatibilities (such as those listed above) and you don't have to deal with them.
There's a better way: dpkg-reconfigure xserver-xfree86
Err, I think that's right. Check the post-halloween document if that doesn't ask the right question.
Assuming you run everything at the default priority (0), the only thing you'll notice is that when you do use the gui, it will be slightly more responsive, due to your cpu-bound application being automatically given a lower priority.
In other words, you probably won't notice any change in behavior.
VM has been modified, mostly with some improved reference counting code (rmap).
The firewall code hasn't been rewritten this time, it's still iptables. Support has been added for using netfilter against a few more things though.
I just realized I'm putting a ton of effort into posting something when I can just link you to the official document: The Post-Halloween Document
Preemption, as you describe it, has been there in every Linux kernel.
Preemption, as Linus referred to it in the release announcement, is Kernel preemption.
I.e, the kernel itself can be preempted. This has improved consistency for things such as xmms.
The problems you complain about are more likely the result of the new scheduler. Tell me, what nice level does X run at on your system? If it's -10, that's why your responsiveness sucks. Stop X from being reniced to -10 from 0 and you'll find that everything performs much smoother. The new scheduler does a much better job of actually respecting priorities, and as such doesn't need adjustements such as "nice" for everyday things such as running an X server.
No, Linus added that *well* after he began receiving contributions from others.
There is no reason to think that Linus has total control over the licensing restrictions that the kernel is distributed under.
Anyone who tells you otherwise is wrong.
If I say something is unclear, generally, I mean "It is unclear to me." I believe that's true of, oh, everyone, when they say that something is unclear.
So, I feel obliged to ponder: How do YOU disagree with my opinion that something is unclear?
Especially when I'm interviewing you saying, in essence, "What the heck is this about?"
I guess I just hate marketing people.
True - and I wasn't really attempting to imply otherwise.
Maybe a better way to describe what I mean - a Blaster equivalent would have more trouble affecting the mail server, in a chroot-protected environment.
In Linux/Unix/BSD, you can preemptively defend against unknown flaws.
That's not possible w/Windows.
(For example, chroot jails to limit exposure, etc.)
Use cvsup.
Then you don't have to copy the whole thing every backup interval, infact, hourly backups of reasonably active repositorys aren't even noticeable.
Luckily, the fixes are usually small enough that they don't impact anyone's configuration. (i.e, it was a bug that could only be triggered when someone was trying to break the system), or, the implications are clearly spelled out during the download process.
Of course, if you're installing 0-day security patches direct from mailing lists and recompiling yourself, you should have a good grasp as to what the patch is doing. If you don't, stick to the packaged versions that DO have review and include warnings telling you what they will be breaking.
Odd, how sysadmins frequently barely fit into that category.
Stopping eth0 will, typically, though.
My watch is a 250 meg flash device with a USB cable attached to it.
The odds of someone noticing it is extremely low.
Heck, when I worked at Chrysler, I wasn't searched, ever. (Worked there for a year.)
Most places can't pull off the security required to prevent internal leaks without making the workplace way too uncomfortable for the honest employees - which is generally a majority of them.
also known as "the September that never ended."
Deleting resumes is always a bad plan, especially if the company ever hires H-1B workers.
If the customer files the response, the ISP is explicitly protected from being liable, so the ISP has no reason not to put the site back up.
Don't get me wrong - the DMCA is bad, but the takedown part is not really the problem.
FYI - the DMCA allows the person whose site is being removed to file a response - the ISP cannot remove the site in that case.
Except the McDonald's lawsuit was, "have cup melt in your lap, spill hot coffee over legs."
You can only configure it based upon keywords?
Debian (well, apt really) has a "Package Priority" system, that lets you selectively pick distributions, versions, etc, of packages to install.
The whole explanation gets complicated - but I have a machine at work that has Perl 5.6.1 installed, but the rest of the distribution comes from either Debian/testing or Debian/unstable, where Perl 5.8.1 is standard. (I have binary compatibility problems that require me to continue doing development against Perl 5.6.1)
Is that easy to do in Gentoo? It seems that a keyword based system would be a bit... limiting in that respect.
(Keep something in mind - most of computing revolves around, "is it good enough?" and not, "This is the best." Gentoo may be neat, but Debian is good enough for me, and the benefits that Gentoo may or may not provide don't seem big enough to make up for the time spent compiling everything, even in a setup where I could use distcc across somewhere around 10 machines.)