Now, if we compare this to/., where approximately six people have a girlfriend, and half of them are girls, we must conclude that nobody on/. actually does anything useful.
It's not possible to go faster than the speed of light in a vacuum. However, it is possible to go faster than light in some medium.
This actually happens fairly often in nuclear physics. Radiation given off by, say, radioactive waste in a nuclear power plant's storage pool can go faster than the speed of light in water. When it does this, you get the eerie blue glow everyone imagines with radioactivity (which usually isn't really there).
This effect is called Cherenkov radiation, unless I've forgotten how to spell.
It is not possible for any medium to speed up light, so far as in known.
The simplest way to understand why light slows down in a medium is to think of it this way:
Light is zooming along at its full vacuum speed, right? But, there are all these atoms there! Zillions of them! So, light runs into an atom. Luckily for light, the way this works is that it temporarily "charges" the atom, which then almost immediately (but not quite) "discharges" a photon going in pretty much the same direction with the same frequency. Depending on how many atoms there are, and how the atoms behave, this can have varying effects on the light.
This isn't really particularly accurate, but it's easy to understand and more or less vaguely similar to how it works.
The trick is to choose your own development team.
Only pick the people you know are competent, or
at least hard working. If everyone does this,
the dumb ones
will all end up stuck in the same group together,
and will either shape up or flunk out.
The only time this doesn't work is then the
professor picks the groups out of a hat. That's
a disaster waiting to happen!
Freeing a pointer twice in the C language is an
error. It is not allowed. It is a security error whether or not you have a heap with some debugging code in it to help you find double frees.
glibc includes double-free checking as others have pointed out - it's just not turned on be default in your average distribution.
It should be understood here that there is a reason the C language specifies a double free as an error. It does this because it is not possible to defend a program against the problems this causes unless one uses a bounds-checking C compiler (there is a GCC project in the works to create one, though of course, with a significant performance loss.)
What glibc and all the other heap implementations on other OS's provide for heap debugging is not a security-quality defense. It does *not* solve the problem and prevent all exploits. What it does is just catch some instances of it, and so reduce the probability that the bug is exploitable.
Ler me give an example. Say you're using some uber-great heap library, that can perfectly know if you're freeing a pointer from the heap.
Consider the following code:
int *a = (int*)malloc(sizeof(int)*10);
int *b;
free(a);
b = (int*)malloc(sizeof(int)*10);
free(a);
read(socket, b, sizeof(int)*10);
Note that a and b could be in completely separate parts of the program, with other calls to the heap in between.
In the example, even with a perfectly error-checking debug-mode heap, you may have just not only misused the heap, but actually caused a buffer overflow error and just had your box rooted as well.
The reason is, there is no guarantee that a does not equal b! In fact, it is not at all unlikely that it will. What happens in this case, though, is that the double free of a is, from the heap's point of view, a legal operation. If a == b, then freeing a is just freeing b. But, the application thinks that b is still valid - so it uses it. This behavior is undefined, and could easily be an exploitable buffer overrun. (BTW, don't think read is safe because it's a system call accessing unallocated memory - the memory is almost certainly still allocated from the OS's point of view)
So, even if they have this heap checking turned on, all the other OS's listed are in principle exploitable via this bug! It just might be less likely. How much less likely depends on how they handle the bug if they can catch it - if they ignore it, it's not much help at all! Of course, exploiting the bug in linux is extremely difficult to begin with, so the real difference here may not amount to much.
This is basically similar to other security hack ideas, like upward-growing stacks and non-executable stacks. Doing that sort of thing *may* prevent some exploits, but the fact that the feature exists is no *guarantee* of safety. It's just a way of reducing the likelihood somewhat.
Just because you have heap debugging turned on by default, doesn't mean you're safe from heap corruption bugs. You're not. It's just somewhat harder to exploit them - but exploiting them is extremely hard to begin with, so whether this translates into any actual security exploits for one but not the other is unknown.
Then do so. The OOM killer (should) only kick in when you're completely out of ram+swap. If you link in a lot of swap space beforehand, it shouldn't take effect.
What you gain by getting rid of overcommit is the ability of user programs to actually fail memory allocation attempts when there's no ram left, instead of having the OS fail them later when the lazy VM gets around to it. This is conceptually somewhat nice, but since there are basically no pieces of software in existence that know how to handle these errors in a reasonable way, it's not very useful in practice.
What you gain by having overcommit is that you can use memory more efficiently, and more quickly. The downside is that when the system runs out of memory, the kernel has to be the one to decide what to do, instead of letting user programs deal with it. The OOM Killer is the kernel's method of dealing with the problem.
Keep in mind here that the OOM Killer in recent kernels has been rather buggy, with an irritating problem of killing processes for no good reason. So, you might see it killing gimp on you when you have hundreds of megs of ram free. A non-buggy OOM Killer should only kill processes when the system's memory has been completely exhausted by some monster ram hog. So to understand the idea properly, imagine that it only kills StarOffice.
The OOM killer is triggered when the system is completely out of all memory, including swap, and a process (any process, not just some ram hog) tries to allocate more. That allocation request cannot complete, so the kernel needs to do something else.
Note that it can't fail the request, because it already passed it due to overcommit.
The OOM killer approach is to find a process that looks ripe and get rid of it. Thus, stability is restored.
Your approach is to freeze the process that wanted a little bit more ram. What do you hope to gain by this? Well, presumably, you think that some other process is going to release some memory and allow the first one to complete. As should be obvious, this may not happen. In fact, it probably won't. What you'll end up with is a dead system with a lot of frozen processes. If you're careful, root might still be able to get in on the console to kill some stuff or link in more swap, but that's about it.
For all practical purposes, the system is hosed.
Your scheme has the advantage for a computation server that the administrator might be able to link in some more swap to complete a computation, but for normal uses, it's just a hang. The OOM killer approach is to attempt to blow away the memory hog and keep the system operational, without administrator intervention.
The other approach, of course, is to get rid of overcommit entirely. People wouldn't like this too much, since they'd need a lot more swap space.
There's a bug in recent 2.4 kernels where a
multithreaded app dumping core could livelock the
system. You might try setting a hard limit on
core file size to zero and see if the crashes
go away.
386's have too little video bandwidth
to do a credible job as a display engine for the
large, hungry apps people use these days. The
same can be said for the majority of 486's,
though they will be somewhat reasonable, and some
will be just fine.
Each X display will also need a significant
amount of RAM, since contrary to what a
previous poster screamed, significant resources
of the application will reside on the display side. For instance, each individual bitmap
graphic will be sent over the network, and then
has to be cached locally to be displayed and worked on. When running something large such as star office or netscape, this will quickly become apparent. However, from experience, a machine with 16MB of ram and swap will be acceptable, and 32MB should be quite nice.
There will also be a pretty significant performance hit when running over the network, though usually the applications are usable. A few, such as Mozilla, and some other heavy-weight graphics applications, will be effectively non-functional. (Though Mozilla will be pretty much non-functional whatever you do, so this isn't a big issue).
Another issue is security - X11 is an extremely insecure protocol, so network sniffing will be a problem. Eg., any password entered on any machine will always go across the network in plaintext by default. This can be rectified using full link encryption, but of course, this requires some horsepower on both ends - a 486 will be hard pressed. But then, in practice, corporate intranets have no security to speak of anyway, so this probably isn't a real concern except as a red herring.
You should also consult state laws on this subject, as some states have regulations on these invention assignment contracts. For instance, Washington State has the following law:
RCW 49.44.140
Requiring assignment of employee's rights to inventions -- Conditions.
(1) A provision in an employment agreement which provides that an employee shall assign or offer to assign any of the employee's
rights in an invention to the employer does not apply to an invention for which no equipment, supplies, facilities, or trade secret
information of the employer was used and which was developed entirely on the employee's own time, unless
(a) the invention relates
(i) directly to the business of the employer, or
(ii) to the employer's actual or demonstrably anticipated research or development, or
(b) the invention results from any work performed by the employee for the employer. Any provision which purports to apply to such
an invention is to that extent against the public policy of this state and is to that extent void and unenforceable.
(2) An employer shall not require a provision made void and unenforceable by subsection (1) of this section as a condition of
employment or continuing employment.
(3) If an employment agreement entered into after September 1, 1979, contains a provision requiring the employee to assign any
of the employee's rights in any invention to the employer, the employer must also, at the time the agreement is made, provide a
written notification to the employee that the agreement does not apply to an invention for which no equipment, supplies, facility, or
trade secret information of the employer was used and which was developed entirely on the employee's own time, unless (a) the
invention relates (i) directly to the business of the employer, or (ii) to the employer's actual or demonstrably anticipated research or
development, or (b) the invention results from any work preformed [performed] by the employee for the employer.
[1979 ex.s. c 177 2.]
Whether such laws apply to you, of course, is another question as, like the above one, they tend to be pretty weak. The employer's rats, er, that is, lawyers, would of course claim that any possible invention involving software relates to their business. You should further subsidize the verminous hordes of these trained rats by hiring one of your very own, instead of asking for some half-assed opinions on the internet.
What's to stop some company from hiring a staff of surrogate mothers to birth clones in some impoverished third world country to mass-produce kidneys and hearts for transplant?
This makes no sense as a business proposition. The advantage of using clones as organ donors is that, if a person had a clone made, that clone would be a perfect match to its progenitor.
Such is not the case for general-purpose clones, which are no better than anyone else as organ donors for the public.
If some company just wanted to mass produce organ donors, they would find it vastly easier to just find a bunch of mothers in third world countries and pay them to get pregnant a lot. Or even easier than that, just go kill people as needed for organs. Why make babies when you can go murder fully grown humans for their parts?
These crazy anti-cloning ideas never have any real basis in logic. The real argument against cloning is just that it's a very spotty procedure that barely works in animals -- until techniques are much improved, it would likely be pretty ineffective in humans. If you get 30 stillbirths and nonviable fetuses per success (and countless more attempts that simply failed in the test tube) it's just going to be an unnecessary risk to the mother.
Just to make sure, I just tested the page again using 0.7, and it was the same speed as before. So, it hasn't improved in regards to laying out a table full of text boxes.
The original test was around M18. There was no 0.5.
This isn't really valid -- look at some of the other good browsers available (Konqueror and Opera for Linux, and IE for 'doze) and you'll notice that all of them smoke the living daylights out of Mozilla, while providing quite capable DOM and reflow (better than Mozilla's, in most cases!).
Sure, they can be a bit pokey at times doing one thing or another, but in general, they just haul compared to the 'zilla.
Really, Mozilla being incredibly slow is probably not really because of the rendering engine being sluggish (though it could probably use some usability tuning). It's more due to the horribly designed theming engine and widget set, as you surmised. A quick look at Galeon should convince anyone of this, and also hint at the even greater speedup that could appear if it was dumped completely.
I recall doing some cheezy benchmarks a couple months ago, and found that on the same machine, rendering a page with a bunch of text boxes (thus hitting the XUL junk hard), IE and Netscape 4.75 were both between 20 and 40 times faster than Mozilla (and had better layout usability as well -- Mozilla just had a blank screen, while IE laid out the table incrementally. NS4 didn't, but didn't freeze up either, or at least, was so fast it didn't appear to freeze up).
Eg., NS and IE laid out the page in under 2 seconds, while Mozilla took more than 20. Taking into account the ~1s server generation lag to create the page, that's rather bad. And, of course, since Mozilla is a massive threaded app, instead of forking off children as it should, it froze up completely during rendering in all windows.
Actually, usability speed, as opposed to "real" speed, is one of the big problems with Mozilla right now. It's often fairly comparable with other browsers at producing a finished product of a page, but is very, very slow in terms of the UI feel. Status bars don't update often, gizmos don't pulse and flash, the page doesn't flash on quickly and then get reflowed, etc. The end result is that it's slow to begin with, and once the nasty UI is through with it, it seems like the days of the 386 have escaped to haunt us.
So, I dumped Photoshop completely and went with the gimp about a year and a half ago when I tried to deal with some 50 meg files in both programs. Photoshop, on a machine with twice as much ram as my home computer, took *half an hour* to save one image. I sent the image home, and guess what? Gimp could do the same thing in 30 seconds, on a slower machine.
Wrong, Mr. Katz. Not voting is nothing more than a big "I don't care." The only message it sends is that you approve of ANY candidate, and that you approve of them all equally. Why? Because ANY OTHER VIEW can be expressed by voting. If you prefer one of them, you vote for them. If you don't like any, you write-in another name, or just don't select any of them - because going to the polls and not picking one still counts as voting.
Wrong.
If you write in a name on the ballot, it will not be counted in most or all states. It will be completely ignored. If 60% of the people filled in a different name, it might be counted, but that person would not be elected because you have to file for the election first.
If you don't select anyone for an office, it will be ignored.
In fact, the only option that actually does get noticed is not voting. The only problem is, not voting is counted as "apathy" not as a "protest." There is no protest vote available besides selecting some third party loonie.
You can make a swap file in linux, and link it in on the fly. Eg:
$ dd if=/dev/zero of=/root/swap.100M bs=1k count=100000
$ mkswap/root/swap.100M
$ sync # Yes, you have to sync
$ swapon/root/swap.100M
So, if you were running low on swap, you could make some more. I recall in times of yore, someone went and wrote a daemon to do this for you when you ran out of memory (though not, presumably, demanding it out from the kernel as necessary, like windows does).
You can also do wild and crazy things with swap, like say running them over the network on a network block device, etc...
If the fonts are small and look ugly, that would probably be because of #2, ugly fonts. (And possibly a lack of hinting in the rasterizer, if they were truetype fonts.)
To fix the bitmap scaling problem, go to your XF86Config (or fs/config if you use the x font server) and find the bit that liike like this:
(There will probably be some keywords in the vicinity)
These are the paths to your fonts. Note that some of them have:unscaled after them, and some don't. You don't ever want to scale bitmap fonts usually, because it looks terrible. Now, note that 75dpi is there with and without:unscaled after it. Take out the line without:unscaled after it, like so:
Note that misc also contains bitmap fonts, so you don't want to scale that either. Type1, Speedo, and Truetype are vector fonts, so scaling them is ok.
Also, if your display is high-res (eg. 1024x768 @ 15", 1280x1024@17", 1600x1200@21", etc) you probably want 100dpi fonts, which you'd set up by installing them and changing that "75" to a "100" in there. Some apps will be confused, but it's much better.
Also, properly speaking, your X server should be set to the correct DPI for your display. Unfortunately, XFree86 is screwed up in this regard, and doesn't work like it should. Some apps (eg. Mozilla) will work better if they know the real DPI and not just the default, 75.
I see all these people bitching about "horribly pixelated fonts" and how anti-aliasing is going to solve all the problems in the world.
Ok, I'll bite. Abiword and all other linux software looks just fine to me. Perhaps I've somehow managed to fall asleep at the keyboard and accidentally managed to add anti-aliased font support to X by rolling my forhead on the keys. Come to think of it, I did have a big headache a few weeks ago...
So, you "horribly pixelated font" people, show me these horribly pixelated fonts. Seriously, I've never seen them. I want to see some screen shots. Please follow up to this message with a link to some screenshots of this horrible non-anti-aliased blight on human eyesight.
I somehow expect what's actually going is that:
People installed Redhat, which out of the box is set to scale bitmap fonts if requested, and thus looks ugly as hell and has nothing at all to do with anti-aliasing whatsoever. (And in fact can be fixed with a 10 second session with XF86Config)
People are complaining because the font glyphs aren't the prettiest with small fonts, which again has nothing at all to do with antialiasing (which only generally applies to larger fonts) and actually has to do with hinting in the rasterizer and in general with the artistic ability of the people who drew the fonts.
People are complaining because they're using a display the size of a blimp at a resolution meant for a postage stamp, and need anti-aliasing to see anything without pain. This is a valid concern, especially for laptops, but I suspect the screenshots will look fine on most peoples' displays.
People are just bellyaching because they heard someone else bitching for the above mentioned reasons, and want to join their voice to the whining crowd.
I can say this because I'm quite familiar with the way most displays look under anti-aliased fonts, and the way they look can best be described as "almost the same." Thus, I somehow don't think that such a minor effect would generate this amount of bellyaching, except through a combination of the above, especially the last one.
So please, put up some screen shots of these horribly pixelated fonts you're seeing, and let us determine for ourselves why they're so bad looking.
It would almost certainly have been easier to develop than the dog-crap they've come up with, which is a nightmare.
It would *certainly* perform better. The performance under linux is, in a word, pathetic. If you'd like 2 words, it's a pathetic joke.
The browser would be less buggy, since they'd avoid the problem of developing a trash widget set in tandem with the application, but could rely on the work of others.
It wouldn't look like someone led a large goat to your computer and induced it to vomit on the screen, the way it does now.
I'm typing this in mozilla right now, and I'm finding bugs in the text widget about as quickly as I'm pressing keys. Do you really think someone who wasn't high on crack would seriously believe that writing an entire UI engine, and the UI, is easier than just writing the UI? The idea is absurd.
But in this day and age where a lot of money is put into designing cool sites that will bring people back, designers are going to go with whatever lets them create glitz and flash. Especially when 95+% of their users have or can easily get the necessary plugins.
Interesting that you'd cite "bringing people back" as the justification for these things. I know I, and in fact most people I know, find these ugly things an almost certain indicator that we'll never return to a site using them. When I see some ugly-as-fuck java'd up flashappy site, that's pretty much it for that site. Sorry, gooood-bye.
How important are these plugins? I have a very knowledgeable friend that designs web pages usign flash script. Bright guy, geek, runs linux at home etc. Last month he point blank told me that "Flash 4.0 will bury html"
And what does he have to base this on? Flash sites are annoying. Note that the best commerce sites on the internet such as Amazon and Yahoo have, in general, their total percentage of flash/java/lameerplugin#27 being, you guessed it, absolutely none whatsoever. If you want people to come to your site, you use HTML. Period. Absolute, utter, final end of story. Nothing says "don't come here, I don't want you to look at this page" more than an irritating "you need a plug in for this page which doesn't exist" popup window.
Sure, a few sites have some fun with these things, but you know what? They're typically "look, we have a cool toy" type of sites. Sites showing off their cute little flash animation, or some silly Java applet or whatnot. Not sites that actually want people to visit them. Either that, or (guess what!) they don't get a lot of visitors.
Another process doing some malloc()s to see your ram isn't a problem - the kernel in this situation is going to zero the ram before that process gets to read from their malloc area, and in any case it won't have any reason to read in from untouched swap.
Generally speaking, while the system is running and permissions are set, there's not going to be any difference between encrypted and unencrypted swap security wise. Programs won't be allowed to read from swap space, and they aren't allowed to read each other's ram or core files, either (at least, not without permission). About the only case where encrypted swap would help while the system is running is if swap was, for some reason, mounted over a network connection or someone was able to otherwise sniff the channel between the system bus and the actual swap storage device. This might be an actual possibility if you were dealing with, say, some sort of thin client which didn't have a hard disk and swapped to the server, for instance. Secrets wouldn't be accidentally transmitted in the clear due to some app on the client being swapped out. I suppose encrypted swap might also be useful in keeping superuser attacks from extracting information which is no longer resident, but was in the past too, but if you have a root compromise, you're screwed anyway.
The real point of encrypted swap space is that it keeps your secret information from showing up in the swap file if someone steals your machine. Normally, the OS doesn't try to keep swap space clean, so whenever something is paged out, it'll just sit there in the swap partition until it gets overwritten. So, if someone stole your computer, they could then just scan through the memory dumps in your swap partition looking for secret data, and they might well find it. There's no way you could ensure that they wouldn't.
Various other methods to encryption, such as zeroing, aren't really going to help. There are a number of flaws to the zeroing idea:
The swap space can only be zeroed when you actually release it. Thus, the OS would clear the swap block when it's no longer in use. This has the disadvantage of causing more disk IO, but more to the point, if the OS never sees the block get released, it never zeroes it out. So, the gestapo kicks down your door and rips the power cord out of the computer, the OS never gets a chance to clear itself out, and they get your secrets too. Bad.
Zeroing the data won't necessarily erase it very well. Look at the wipe utility and all the hoops it has to go to in an attempt to securely erase data from your disk (and even then, it has flaws). It's very possible for someone to go over a swap partition that's been zeroed, and still recover data, even if it was erased a couple times.
So, basically, it's a lot better to guarantee that your secret is never written to disk at all in an unencrypted form, if you're really worried about it. That means, either you encrypt the swap file, which is a general solution, or you write your software so that, if it knows it has a secret, it will make sure the secret is never written to swap (for instance, by locking the secret in ram so it can't be paged out). The latter solution is good practice, but it's very hard to ensure it works properly.
I applied for a job a couple years ago, and they wanted to do a background check. So, I agreed.
Anyway, a few days later I get this somewhat frantic call telling me the background check has revealed I am a divorced middle aged woman named Tracy who lives in Utah and who's just declared bankruptcy. Seeing how I'm male, college aged, don't live in Utah, and my name is not Tracy, this was bit of a surprise to me.
Of course, with such an amazing result, the company didn't exactly buy the background check, so I was immediately hired. What was interesting was what happened when I tried calling up Trans Union to see what sort of crack they were smoking.
So, you know, I call up their complaints dept., and they put me on hold for half an hour. So, eventually, some greasy sounding guy picks up. I tell him they just told a company that I was, you know, a divorced middle aged woman named Tracy etc.
The guy says, "No! No! Impossible!" and then goes and types for about 5 minutes. I hear him sort of mumble, "Ah, here it is..." or something like that. Then he comes back and says, "No, that's impossible. We correctly check every single data item we're given, and never make mistakes. I don't know what your investigators were thinking, but we never gave out any such information. There is no record of any such data ever existing, and no record that it was ever given to any third party. The computer clearly says we gave out your record and your record only! *click*"
Anyway, I called them back a few times to find out whether I could have some of what they were smoking, and all their successive representatives would instantly check the record and say, "No, no sir, I don't know what you're talking about. We have no record of ever giving out any such information etc."
So, anyway, as for suing these people, expect to be dealing with slime. You might get somewhere with a detective firm I suppose, but the credit bureaus seem to reach levels of dishonesty exceeding even Microsoft's. They seem to be complete scum and very adept at falsification of evidence and destruction of records.
This is already supported in the kernel. You just need to export the server filesystems with NFS, and set up the clients to boot with NFS as the root filesystem.
What you want is basically to just set up the server with the software for the clients exported over NFS, and a bootable area for the clients. IE, you'll set up a directory tree on the server which will work as a root directory for your clients (with some separate writable space for each client). You'll then probably end up making a boot disk for your clients (easier than getting your NICs to use a boot rom), with a linux kernel on it set up for booting with NFS as the root directory.
Except for the little trivialities, like:
Setting up the server side root dir for the clients properly
Setting up the NFS root kernel and the boot disks
this is a complete no-brainer. Nothing to it.
A few tips:
Read the NFSROOT howto. This would be a good place to start. Also, Documentation/nfsroot.txt in the kernel distro.
You're going to want to format the boot disks with some sort of filesystem and put lilo on them, and pass the nfsroot kernel command line through lilo.
You'll want kernel DHCP for the room full of machines, but start with static ip's.
Start off with your boot sequence simple. Use a statically linked ash or something as your init command, and just get the client to actually boot. Then worry about making it do something useful.
Remember that each client needs some writable space of its own to use during booting. For example, they need to write to mtab, so they can mount filesystems correctly, and/var would be a good idea for storing some PID's etc. They can all share/bin,/sbin,/usr,/lib,/dev,/opt etc. It would be a good idea to give them separate/tmp directories as well.
A couple other things:
The disk access on the server isn't a problem. The most recently used files on the disk are automatically cached. If you really want more control, you could use ram disks, but it would probably be less efficient.
One thing you may be concerned about is that you can't currently set up a swap file for each client over NFS. This means you may have a problem with running out of ram on the client machines. (There may be a patch available for this, or you might be able to use some other network file system) You could put a hard disk in each one for swapping, but that would obviously defeat the purpose of running them over the network. Make sure the clients have sufficient ram for normal operation.
Performance may not be the greatest, that sort of thing.
Remember to compile the client kernel right. You know, don't build the things you need to boot, such as, say, the NIC drivers, as modules, because that wouldn't work too well.
Slashdot Mirror
It's true. Look at the study.
Now, if we compare this to /., where approximately six people have a girlfriend, and half of them are girls, we must conclude that nobody on /. actually does anything useful.
<G>
It's not possible to go faster than the speed of light in a vacuum. However, it is possible to go faster than light in some medium.
This actually happens fairly often in nuclear physics. Radiation given off by, say, radioactive waste in a nuclear power plant's storage pool can go faster than the speed of light in water. When it does this, you get the eerie blue glow everyone imagines with radioactivity (which usually isn't really there).
This effect is called Cherenkov radiation, unless I've forgotten how to spell.
It is not possible for any medium to speed up light, so far as in known.
The simplest way to understand why light slows down in a medium is to think of it this way:
Light is zooming along at its full vacuum speed, right? But, there are all these atoms there! Zillions of them! So, light runs into an atom. Luckily for light, the way this works is that it temporarily "charges" the atom, which then almost immediately (but not quite) "discharges" a photon going in pretty much the same direction with the same frequency. Depending on how many atoms there are, and how the atoms behave, this can have varying effects on the light.
This isn't really particularly accurate, but it's easy to understand and more or less vaguely similar to how it works.
Of course, IANAP.
Worked ok at my school, most of the time.
The trick is to choose your own development team. Only pick the people you know are competent, or at least hard working. If everyone does this, the dumb ones will all end up stuck in the same group together, and will either shape up or flunk out.
The only time this doesn't work is then the professor picks the groups out of a hat. That's a disaster waiting to happen!
glibc includes double-free checking as others have pointed out - it's just not turned on be default in your average distribution.
It should be understood here that there is a reason the C language specifies a double free as an error. It does this because it is not possible to defend a program against the problems this causes unless one uses a bounds-checking C compiler (there is a GCC project in the works to create one, though of course, with a significant performance loss.)
What glibc and all the other heap implementations on other OS's provide for heap debugging is not a security-quality defense. It does *not* solve the problem and prevent all exploits. What it does is just catch some instances of it, and so reduce the probability that the bug is exploitable.
Ler me give an example. Say you're using some uber-great heap library, that can perfectly know if you're freeing a pointer from the heap.
Consider the following code:
int *a = (int*)malloc(sizeof(int)*10);
int *b;
free(a);
b = (int*)malloc(sizeof(int)*10);
free(a);
read(socket, b, sizeof(int)*10);
Note that a and b could be in completely separate parts of the program, with other calls to the heap in between.
In the example, even with a perfectly error-checking debug-mode heap, you may have just not only misused the heap, but actually caused a buffer overflow error and just had your box rooted as well.
The reason is, there is no guarantee that a does not equal b! In fact, it is not at all unlikely that it will. What happens in this case, though, is that the double free of a is, from the heap's point of view, a legal operation. If a == b, then freeing a is just freeing b. But, the application thinks that b is still valid - so it uses it. This behavior is undefined, and could easily be an exploitable buffer overrun. (BTW, don't think read is safe because it's a system call accessing unallocated memory - the memory is almost certainly still allocated from the OS's point of view)
So, even if they have this heap checking turned on, all the other OS's listed are in principle exploitable via this bug! It just might be less likely. How much less likely depends on how they handle the bug if they can catch it - if they ignore it, it's not much help at all! Of course, exploiting the bug in linux is extremely difficult to begin with, so the real difference here may not amount to much.
This is basically similar to other security hack ideas, like upward-growing stacks and non-executable stacks. Doing that sort of thing *may* prevent some exploits, but the fact that the feature exists is no *guarantee* of safety. It's just a way of reducing the likelihood somewhat.
Just because you have heap debugging turned on by default, doesn't mean you're safe from heap corruption bugs. You're not. It's just somewhat harder to exploit them - but exploiting them is extremely hard to begin with, so whether this translates into any actual security exploits for one but not the other is unknown.
What you gain by getting rid of overcommit is the ability of user programs to actually fail memory allocation attempts when there's no ram left, instead of having the OS fail them later when the lazy VM gets around to it. This is conceptually somewhat nice, but since there are basically no pieces of software in existence that know how to handle these errors in a reasonable way, it's not very useful in practice.
What you gain by having overcommit is that you can use memory more efficiently, and more quickly. The downside is that when the system runs out of memory, the kernel has to be the one to decide what to do, instead of letting user programs deal with it. The OOM Killer is the kernel's method of dealing with the problem.
Keep in mind here that the OOM Killer in recent kernels has been rather buggy, with an irritating problem of killing processes for no good reason. So, you might see it killing gimp on you when you have hundreds of megs of ram free. A non-buggy OOM Killer should only kill processes when the system's memory has been completely exhausted by some monster ram hog. So to understand the idea properly, imagine that it only kills StarOffice.
The OOM killer is triggered when the system is completely out of all memory, including swap, and a process (any process, not just some ram hog) tries to allocate more. That allocation request cannot complete, so the kernel needs to do something else. Note that it can't fail the request, because it already passed it due to overcommit.
The OOM killer approach is to find a process that looks ripe and get rid of it. Thus, stability is restored.
Your approach is to freeze the process that wanted a little bit more ram. What do you hope to gain by this? Well, presumably, you think that some other process is going to release some memory and allow the first one to complete. As should be obvious, this may not happen. In fact, it probably won't. What you'll end up with is a dead system with a lot of frozen processes. If you're careful, root might still be able to get in on the console to kill some stuff or link in more swap, but that's about it.
For all practical purposes, the system is hosed.
Your scheme has the advantage for a computation server that the administrator might be able to link in some more swap to complete a computation, but for normal uses, it's just a hang. The OOM killer approach is to attempt to blow away the memory hog and keep the system operational, without administrator intervention.
The other approach, of course, is to get rid of overcommit entirely. People wouldn't like this too much, since they'd need a lot more swap space.
http://www.mplayerhq.hu/homepage/
It handles mpeg, old avi, divx, wmv, asf, etc.
It doesn't handle RealVideo, but you can get the RealPlayer for that.
It doesn't handle Sorensen Quicktime, but you can get the crossover plugin for that.
That leaves the only relevant format that doesn't play as... Um... Wait, that's all of 'em.
There's a bug in recent 2.4 kernels where a multithreaded app dumping core could livelock the system. You might try setting a hard limit on core file size to zero and see if the crashes go away.
You'd want to do this in /etc/profile, of
course.
Each X display will also need a significant amount of RAM, since contrary to what a previous poster screamed, significant resources of the application will reside on the display side. For instance, each individual bitmap graphic will be sent over the network, and then has to be cached locally to be displayed and worked on. When running something large such as star office or netscape, this will quickly become apparent. However, from experience, a machine with 16MB of ram and swap will be acceptable, and 32MB should be quite nice.
There will also be a pretty significant performance hit when running over the network, though usually the applications are usable. A few, such as Mozilla, and some other heavy-weight graphics applications, will be effectively non-functional. (Though Mozilla will be pretty much non-functional whatever you do, so this isn't a big issue).
Another issue is security - X11 is an extremely insecure protocol, so network sniffing will be a problem. Eg., any password entered on any machine will always go across the network in plaintext by default. This can be rectified using full link encryption, but of course, this requires some horsepower on both ends - a 486 will be hard pressed. But then, in practice, corporate intranets have no security to speak of anyway, so this probably isn't a real concern except as a red herring.
You should also consult state laws on this subject, as some states have regulations on these invention assignment contracts. For instance, Washington State has the following law:
Whether such laws apply to you, of course, is another question as, like the above one, they tend to be pretty weak. The employer's rats, er, that is, lawyers, would of course claim that any possible invention involving software relates to their business. You should further subsidize the verminous hordes of these trained rats by hiring one of your very own, instead of asking for some half-assed opinions on the internet.
This makes no sense as a business proposition. The advantage of using clones as organ donors is that, if a person had a clone made, that clone would be a perfect match to its progenitor.
Such is not the case for general-purpose clones, which are no better than anyone else as organ donors for the public.
If some company just wanted to mass produce organ donors, they would find it vastly easier to just find a bunch of mothers in third world countries and pay them to get pregnant a lot. Or even easier than that, just go kill people as needed for organs. Why make babies when you can go murder fully grown humans for their parts?
These crazy anti-cloning ideas never have any real basis in logic. The real argument against cloning is just that it's a very spotty procedure that barely works in animals -- until techniques are much improved, it would likely be pretty ineffective in humans. If you get 30 stillbirths and nonviable fetuses per success (and countless more attempts that simply failed in the test tube) it's just going to be an unnecessary risk to the mother.
Just to make sure, I just tested the page again using 0.7, and it was the same speed as before. So, it hasn't improved in regards to laying out a table full of text boxes.
The original test was around M18. There was no 0.5.
This isn't really valid -- look at some of the other good browsers available (Konqueror and Opera for Linux, and IE for 'doze) and you'll notice that all of them smoke the living daylights out of Mozilla, while providing quite capable DOM and reflow (better than Mozilla's, in most cases!).
Sure, they can be a bit pokey at times doing one thing or another, but in general, they just haul compared to the 'zilla.
Really, Mozilla being incredibly slow is probably not really because of the rendering engine being sluggish (though it could probably use some usability tuning). It's more due to the horribly designed theming engine and widget set, as you surmised. A quick look at Galeon should convince anyone of this, and also hint at the even greater speedup that could appear if it was dumped completely.
I recall doing some cheezy benchmarks a couple months ago, and found that on the same machine, rendering a page with a bunch of text boxes (thus hitting the XUL junk hard), IE and Netscape 4.75 were both between 20 and 40 times faster than Mozilla (and had better layout usability as well -- Mozilla just had a blank screen, while IE laid out the table incrementally. NS4 didn't, but didn't freeze up either, or at least, was so fast it didn't appear to freeze up).
Eg., NS and IE laid out the page in under 2 seconds, while Mozilla took more than 20. Taking into account the ~1s server generation lag to create the page, that's rather bad. And, of course, since Mozilla is a massive threaded app, instead of forking off children as it should, it froze up completely during rendering in all windows.
Actually, usability speed, as opposed to "real" speed, is one of the big problems with Mozilla right now. It's often fairly comparable with other browsers at producing a finished product of a page, but is very, very slow in terms of the UI feel. Status bars don't update often, gizmos don't pulse and flash, the page doesn't flash on quickly and then get reflowed, etc. The end result is that it's slow to begin with, and once the nasty UI is through with it, it seems like the days of the 386 have escaped to haunt us.
Here are some informal Mozilla snappiness results:
- Pentium 90: Boot does not complete
- K6/266: Painful
- Dual Xeon 600 w/512 megs of ram: Not snappy
- PIII 933 with 256 megs of ram: Quite snappy (except for loading of course)
Thus, let it be known: The minimum system configuration for Mozilla is a PIII-933 with 256 megs of ram.So, I dumped Photoshop completely and went with the gimp about a year and a half ago when I tried to deal with some 50 meg files in both programs. Photoshop, on a machine with twice as much ram as my home computer, took *half an hour* to save one image. I sent the image home, and guess what? Gimp could do the same thing in 30 seconds, on a slower machine.
Sorry. Photoshop just plain loses.
Wrong.
If you write in a name on the ballot, it will not be counted in most or all states. It will be completely ignored. If 60% of the people filled in a different name, it might be counted, but that person would not be elected because you have to file for the election first.
If you don't select anyone for an office, it will be ignored.
In fact, the only option that actually does get noticed is not voting. The only problem is, not voting is counted as "apathy" not as a "protest." There is no protest vote available besides selecting some third party loonie.
You can make a swap file in linux, and link it in on the fly. Eg:
/root/swap.100M
/root/swap.100M
$ dd if=/dev/zero of=/root/swap.100M bs=1k count=100000
$ mkswap
$ sync # Yes, you have to sync
$ swapon
So, if you were running low on swap, you could make some more. I recall in times of yore, someone went and wrote a daemon to do this for you when you ran out of memory (though not, presumably, demanding it out from the kernel as necessary, like windows does).
You can also do wild and crazy things with swap, like say running them over the network on a network block device, etc...
Here's an easy way to make a full image backup of your NT server:
As usual, Linux can solve your NT problems. :-)
Hmm... Someone should make a boot disk to do this automatically. Would probably fit on one floppy. You wouldn't even have to press 1 ;-)
If the fonts are small and look ugly, that would probably be because of #2, ugly fonts. (And possibly a lack of hinting in the rasterizer, if they were truetype fonts.)
To fix the bitmap scaling problem, go to your XF86Config (or fs/config if you use the x font server) and find the bit that liike like this:
(There will probably be some keywords in the vicinity)
These are the paths to your fonts. Note that some of them have :unscaled after them, and some don't. You don't ever want to scale bitmap fonts usually, because it looks terrible. Now, note that 75dpi is there with and without :unscaled after it. Take out the line without :unscaled after it, like so:
Note that misc also contains bitmap fonts, so you don't want to scale that either. Type1, Speedo, and Truetype are vector fonts, so scaling them is ok.
Also, if your display is high-res (eg. 1024x768 @ 15", 1280x1024@17", 1600x1200@21", etc) you probably want 100dpi fonts, which you'd set up by installing them and changing that "75" to a "100" in there. Some apps will be confused, but it's much better.
Also, properly speaking, your X server should be set to the correct DPI for your display. Unfortunately, XFree86 is screwed up in this regard, and doesn't work like it should. Some apps (eg. Mozilla) will work better if they know the real DPI and not just the default, 75.
I see all these people bitching about "horribly pixelated fonts" and how anti-aliasing is going to solve all the problems in the world.
Ok, I'll bite. Abiword and all other linux software looks just fine to me. Perhaps I've somehow managed to fall asleep at the keyboard and accidentally managed to add anti-aliased font support to X by rolling my forhead on the keys. Come to think of it, I did have a big headache a few weeks ago...
So, you "horribly pixelated font" people, show me these horribly pixelated fonts. Seriously, I've never seen them. I want to see some screen shots. Please follow up to this message with a link to some screenshots of this horrible non-anti-aliased blight on human eyesight.
I somehow expect what's actually going is that:I can say this because I'm quite familiar with the way most displays look under anti-aliased fonts, and the way they look can best be described as "almost the same." Thus, I somehow don't think that such a minor effect would generate this amount of bellyaching, except through a combination of the above, especially the last one.
So please, put up some screen shots of these horribly pixelated fonts you're seeing, and let us determine for ourselves why they're so bad looking.
Thank you.
Well, there's an easy question if I ever saw one.
I'd do 1, in a heartbeat.
I'm typing this in mozilla right now, and I'm finding bugs in the text widget about as quickly as I'm pressing keys. Do you really think someone who wasn't high on crack would seriously believe that writing an entire UI engine, and the UI, is easier than just writing the UI? The idea is absurd.
But in this day and age where a lot of money is put into designing cool sites that will bring people back, designers are going to go with whatever lets them create glitz and flash. Especially when 95+% of their users have or can easily get the necessary plugins.
Interesting that you'd cite "bringing people back" as the justification for these things. I know I, and in fact most people I know, find these ugly things an almost certain indicator that we'll never return to a site using them. When I see some ugly-as-fuck java'd up flashappy site, that's pretty much it for that site. Sorry, gooood-bye.
How important are these plugins? I have a very knowledgeable friend that designs web pages usign flash script. Bright guy, geek, runs linux at home etc. Last month he point blank told me that "Flash 4.0 will bury html"
And what does he have to base this on? Flash sites are annoying. Note that the best commerce sites on the internet such as Amazon and Yahoo have, in general, their total percentage of flash/java/lameerplugin#27 being, you guessed it, absolutely none whatsoever. If you want people to come to your site, you use HTML. Period. Absolute, utter, final end of story. Nothing says "don't come here, I don't want you to look at this page" more than an irritating "you need a plug in for this page which doesn't exist" popup window.
Sure, a few sites have some fun with these things, but you know what? They're typically "look, we have a cool toy" type of sites. Sites showing off their cute little flash animation, or some silly Java applet or whatnot. Not sites that actually want people to visit them. Either that, or (guess what!) they don't get a lot of visitors.
Another process doing some malloc()s to see your ram isn't a problem - the kernel in this situation is going to zero the ram before that process gets to read from their malloc area, and in any case it won't have any reason to read in from untouched swap.
Generally speaking, while the system is running and permissions are set, there's not going to be any difference between encrypted and unencrypted swap security wise. Programs won't be allowed to read from swap space, and they aren't allowed to read each other's ram or core files, either (at least, not without permission). About the only case where encrypted swap would help while the system is running is if swap was, for some reason, mounted over a network connection or someone was able to otherwise sniff the channel between the system bus and the actual swap storage device. This might be an actual possibility if you were dealing with, say, some sort of thin client which didn't have a hard disk and swapped to the server, for instance. Secrets wouldn't be accidentally transmitted in the clear due to some app on the client being swapped out. I suppose encrypted swap might also be useful in keeping superuser attacks from extracting information which is no longer resident, but was in the past too, but if you have a root compromise, you're screwed anyway.
The real point of encrypted swap space is that it keeps your secret information from showing up in the swap file if someone steals your machine. Normally, the OS doesn't try to keep swap space clean, so whenever something is paged out, it'll just sit there in the swap partition until it gets overwritten. So, if someone stole your computer, they could then just scan through the memory dumps in your swap partition looking for secret data, and they might well find it. There's no way you could ensure that they wouldn't.
Various other methods to encryption, such as zeroing, aren't really going to help. There are a number of flaws to the zeroing idea:
- The swap space can only be zeroed when you actually release it. Thus, the OS would clear the swap block when it's no longer in use. This has the disadvantage of causing more disk IO, but more to the point, if the OS never sees the block get released, it never zeroes it out. So, the gestapo kicks down your door and rips the power cord out of the computer, the OS never gets a chance to clear itself out, and they get your secrets too. Bad.
- Zeroing the data won't necessarily erase it very well. Look at the wipe utility and all the hoops it has to go to in an attempt to securely erase data from your disk (and even then, it has flaws). It's very possible for someone to go over a swap partition that's been zeroed, and still recover data, even if it was erased a couple times.
So, basically, it's a lot better to guarantee that your secret is never written to disk at all in an unencrypted form, if you're really worried about it. That means, either you encrypt the swap file, which is a general solution, or you write your software so that, if it knows it has a secret, it will make sure the secret is never written to swap (for instance, by locking the secret in ram so it can't be paged out). The latter solution is good practice, but it's very hard to ensure it works properly.I applied for a job a couple years ago, and they wanted to do a background check. So, I agreed.
Anyway, a few days later I get this somewhat frantic call telling me the background check has revealed I am a divorced middle aged woman named Tracy who lives in Utah and who's just declared bankruptcy. Seeing how I'm male, college aged, don't live in Utah, and my name is not Tracy, this was bit of a surprise to me.
Of course, with such an amazing result, the company didn't exactly buy the background check, so I was immediately hired. What was interesting was what happened when I tried calling up Trans Union to see what sort of crack they were smoking.
So, you know, I call up their complaints dept., and they put me on hold for half an hour. So, eventually, some greasy sounding guy picks up. I tell him they just told a company that I was, you know, a divorced middle aged woman named Tracy etc.
The guy says, "No! No! Impossible!" and then goes and types for about 5 minutes. I hear him sort of mumble, "Ah, here it is..." or something like that. Then he comes back and says, "No, that's impossible. We correctly check every single data item we're given, and never make mistakes. I don't know what your investigators were thinking, but we never gave out any such information. There is no record of any such data ever existing, and no record that it was ever given to any third party. The computer clearly says we gave out your record and your record only! *click*"
Anyway, I called them back a few times to find out whether I could have some of what they were smoking, and all their successive representatives would instantly check the record and say, "No, no sir, I don't know what you're talking about. We have no record of ever giving out any such information etc."
So, anyway, as for suing these people, expect to be dealing with slime. You might get somewhere with a detective firm I suppose, but the credit bureaus seem to reach levels of dishonesty exceeding even Microsoft's. They seem to be complete scum and very adept at falsification of evidence and destruction of records.
This is already supported in the kernel. You just need to export the server filesystems with NFS, and set up the clients to boot with NFS as the root filesystem.
What you want is basically to just set up the server with the software for the clients exported over NFS, and a bootable area for the clients. IE, you'll set up a directory tree on the server which will work as a root directory for your clients (with some separate writable space for each client). You'll then probably end up making a boot disk for your clients (easier than getting your NICs to use a boot rom), with a linux kernel on it set up for booting with NFS as the root directory.
Except for the little trivialities, like:
this is a complete no-brainer. Nothing to it.
A few tips:
A couple other things: