schitzophrenia [sic] is not multiple personalities, that one is called "disassociative identity disorder"
Yeah but hillbillies want to be called 'Sons of the Soil', but it's never going to happen....
I'm not sure where you're going with that one... Sure, in general usage a language is defined by the whims of the people who speak it. But when it's technical jargon - in this case medical jargon - the technical definition, as opposed to "what everyone calls it" is rather important! I've had friends who call a CRT monitor "the computer", yet my CRT is still unable to function without the part that the geeks refer to as "the computer". Sometimes the commonly used phrase can be technically wrong and therefore misleading, despite the fact that it's popular.
There's also a wider point at stake here: in general, we reserve the right to change the generally accepted meaning of words in the English language (presumably ditto for most other living languages) according to what most people understand them to mean. This typically does not happen in the same way within technical disciplines; physicists draw a distinction between "speed" and "velocity" and show no signs of changing. Usually what terms the techies appropriate to mean something very specific does not affect the rest of us - there's not much point in me labouring the distinction between monitor and computer with my friends, since the misunderstanding doesn't really hurt anyone. This is not the case for medical terminology, where the name of the disease tends to become a label for the sufferers in discussion, as well as a convenient way for a sufferer to explain their condition to an interested third party. The names of diseases have specific technical meanings to a Doctor but are often also used in everyday conversation between people explaining their health situation.
Doctors aren't going to alter the names of diseases just because common usage often confuses a couple of them - it's technical jargon and there's no sense creating confusion in the medical community by changing that around. So it's up to the rest of us: do we want to stick the wrong label on an ill person because it's a generally accepted misunderstanding, or do we attempt to clarify the differences between disorders, knowing that a greater understanding and better use of the terminology is the only way the confusion will ever be resolved.
I'm sticking with the latter approach since it raises public awareness of important issues, even though I know there will always be people who remain confused about the distinction.
NILFS2 (http://www.nilfs.org/en/) is actually a pretty interesting filesystem. It's a log-structured filesystem, meaning that it treats your disk as a big circular logging device.
Log structured filesystems were originally developed by the research community (e.g. see the paper on Sprite LFS here, which is the first example that I'm aware of: http://www.citeulike.org/user/Wombat/article/208320) to improve disk performance. The original assumption behind Sprite LFS was that you'll have lots of memory, so you'll be able to mostly service data reads from your cache rather than needing to go to disk; however, writes to files are still awkward as you typically need to seek around to the right locations on the disk. Sprite LFS took the approach of buffering writes in memory for a time and then squirting a big batch of them onto the disk sequentially at once, in the form of a "log" - doing a big sequential write of all the changes onto the same part of the disk maximised the available write bandwidth. This approach implies that data was not being altered in place, so it was also necessary to write - also into the log - new copies of the inodes whose contents were altered. The new inode would point to the original blocks for unmodified areas of the file and include pointers to the new blocks for any parts of the file that got altered. You can find out the most recent state of a file by finding the inode for that file that has most recently been written to the log.
This design has a load of nice properties, such as: * You get good write bandwidth, even when modifying small files, since you don't have to keep seeking the disk head to make in-place changes. * The filesystem doesn't need a lengthy fsck to recover from crash (although it's not "journaled" like other filesystems, effectively the whole filesystem *is* one big journal and that gives you similar properties) * Because you're not repeatedly modifying the same bit of disk it could potentially perform better and cause less wear on an appropriately-chosen flash device (don't know how much it helps on an SSD that's doing its own block remapping / wear levelling...). One of the existing flash filesystems for Linux (JFFS2, I *think*) is log structured.
In the case of NILFS2 they've exploited the fact that inodes are rewritten when their contents are modified to give you historical snapshots that should be essentially "free" as part of the filesystem's normal operation. They have the filesystem frequently make automatic checkpoints of the entire filesystem's state. These will normally be deleted after a time but you have the option of making any of them permanent. Obviously if you just keep logging all changes to a disk it'll get filled up, so there's typically a garbage collector daemon of some kind that "repacks" old data, deletes stuff that's no longer needed, frees disk space and potentially optimises file layout. This is necessary for long term operation of a log structured filesystem, though not necessary if running read-only.
Another modern log structured FS is DragonflyBSD's HAMMER (http://www.dragonflybsd.org/hammer/), which is being ported to Linux as a SoC project, I think (http://hammerfs-ftw.blogspot.com/)
unless you believe in the possibility of some magic side-effect whereby the processor is slowed down because you're using a different filesystem. (It's just about possible, e.g. if the filesystem gobbles lots of memory and causes your machine to thrash, but in the real world it's a waste of time running these things.)
Some filesystems have higher CPU usage - aside from issues of data structure complexity, btrfs does a load of extra checksumming, for instance.
But your point stands that CPU-bound benchmarks are probably not the best way of measuring a filesystem. It would be interesting to measure CPU usage whilst running a filesystem-intensive workload, or even to measure this indirectly through the slowdown of bzip2 compression whilst running a filesystem-intensive workload in the background.
Should that Giant Magnetoresistive? Someone else seems to so because the article is tagged "typoinsummary". Google and I haven't heard much about Great Magnetoresistive effect in the past, so unless it's some obscure term...
But hey, it's not my area of expertise and I certainly agree that with the sentiment that this magnetoresistive stuff is rather great!
Argh, so I'm turning into the kind of person who comments without reading *either* article in question but...
Last time this came up, plenty of people pointed out that the G1 garbage collector was available to anyone, Open Source but that it was in development and you weren't recommended to use it in production without a support contract. A number of people even pointed out the settings that anybody could change to enable the experimental G1 garbage collector on their own system.
Perhaps this is case of adjusting their wording to make it easier for Slashdot to not report incorrectly;-)
"the real competition between the Zune HD and the iPod Touch will come down to software. The new Zune will be based on a custom version of Windows CE, while the iPod Touch runs on the already popular iPhone platform, for which thousands of applications are available"
So the main weakness of the Microsoft platform is that very little popular software appears to be available for it, whereas the Apple equivalent is where all the apps are... If anybody fell asleep a few years ago and woke up to this they are going to be very confused!
I'd say this is simultaneously an example of: a) how if MS produce a platform that many users prefer - like Apple originally did with the iPhone - that the application builders Will Come. b) just what an incredible job Apple's simultaneous technical and marketing pushes have done for their entry into the phone market.
It'll be interesting to see what trends emerge for MS and Apple in the future.
When I go into my local butchers, sometimes the radio is on. The butchers have to buy a license from the PRS - there's a letter on the wall certifying that they have, in fact, paid for the license to play radio in public. If people were going "Oh, I don't really want any bacon today... hmmm, I do really dig the music at the butchers, though! Lets go anyhow..." then perhaps it would be a *little* understandable (though not necessarily reasonable) that PRS wanted a share of the profits. But I really really don't think people are going to the butcher to listen to music and party amongst the cold meats. In any case I can already listen to the same stuff on my own radio!
Perhaps whilst they're reducing their rates the PRS could relax some of their more ridiculous rules about public listening and then I can afford (marginally) more bacon. Om nom nom nom.
The Pandora people have posted plenty of pictures and videos of their prototypes, working units, production samples, etc to demonstrate that their project is real.
There was a Linux-based console that turned out to be a scam recently but it wasn't the Pandora. Perhaps you are thinking of that?
Now they have stuff like Plasma running on Windows I expect they'll do a full shell replacement... debatable how useful that is but I think it'd be pretty fun to have anyhow! And the prospect of a common desktop shell across all the operating systems in an organisation is intriguing.
As for running KDE apps, e.g. Okular on Windows, they're not running an entire desktop under Windows, you're running one app that uses a cross-platform toolkit. If you use Firefox or Opera you would also be using a cross-platform toolkit, rather than simply native Windows APIs.
You could probably argue that having all the KDE goop is overkill but it's still not quite the same as running a whole desktop, which would suggest to me a separate taskbar, filemanager, menu, etc and no integration with the rest of Windows. AFAIK KDE apps for Windows run quite happily as individual apps, no need to start up the rest of the desktop.
My experience of Okular (and its predecessor, kpdf) is that it's quite fast to render, much faster to start than Adobe's own readers typically are, integrates nicely with my desktop (tbf I'm using KDE so you'd expect it to).
My work involves reading a lot of PDF's, so Okular is a KDE4 killer app. As a result I've not installed Adobe's reader on this machine in ages.
If I used Windows / Mac more I'd definitely want it on those platforms too!
You can probably use Okular via the KDE for Windows port, though I don't know if that's had an official stable release yet; don't really use Windows much, otherwise I'd look into it more since in my experience it's a nice app than Adobe's offerings tend to be, whilst still being fast and featureful.
Okular might well work on MacOS X via the KDE for Mac stuff - same caveats but I don't own a Mac so I've *never* tried this;-)
It's funny - when people talk about Linux being hard to use nowadays I think back to myself as a gaming-hungry young teenager with no formal computer training. I would busily pack the minimum essential drivers as efficiently as possible into RAM so that sound and the cool joystick animations would work in Wing Commander 2. I wasn't doing it to tinker, it was just the way we used PCs. A different OS configuration for each individual game and another one entirely for Windows. Nice.
Every so often I step back and think that being able to run multiple apps *at once* without rebooting into effectively a different OS is a lot more user friendly than how I started out in PCs;-)
To be fair, the MS-DOS memory management fiddling was also more painful than my Sinclair Spectrum machines - they loaded software off squealing tape drives but at least software worked out of the box (usually). But I digress...
When I did my CompSci degree at Cambridge, UK we were given lectures by all the currently living previous heads of department. The old was Maurice Wilkes (http://en.wikipedia.org/wiki/Maurice_Vincent_Wilkes). He's an amazing chap, last I heard he was still going into the department to work on a regular basis (!) having been born in 1913.
Anyhow, he showed us a picture of himself standing next to The First Hard Drive (cue angelic chorus) as demonstrated by IBM. It was about as tall as a man, the platters were exposed to view and there was (IIRC) only one head, which looked like a big robot arm. To read from different platters it pulled out of the assembly, moved up and down, then moved into the drive again. Unbelievable that they've become so tiny and intricate. IIRC (I'm probably a bit off!) that first drive had a capacity of about a megabyte or so.
Maurice Wilkes is also credited as the first person recorded as suggesting the idea of the "subroutine". According to Wikipedia, he also came up with the ideas of symbolic labels and macros. Must have been amazing to do such fundamental work and then be able to see the field develop as it has now!
One of the computers he built had a "Stop machine and ring bell for operator attention" so I guess not every thing that he did has become fundamental to our field... merely many of them;-)
Don't remember the MX. I had a ZX, though and I shelled out for a microdrive for a birthday. It was pretty cool, as were the microfloppies themselves. They weren't terribly reliable.
For the QL they upped the storage capacity on the microfloppies by.... changing the speed of the drive motor! Hurrah for old tech;-)
I saw a picture somewhere of an old mainframe / minicomputer with approximately a giant version of the Sinclair microfloppy technology - it just looked like a big box with a pile of tape in it and the two ends of the tape going out the top of the box to the head. Seeing that, I could understand how my little microfloppy drive used to munch up the cartridges (so cute, though!).
I went to a lecture on the QL only a few years ago by my local computer preservation society. Apparently it had a windowed interface and a pre-emptively multitasking OS - took PCs years (decades even, depending on if you were a home user!) to catch up. I understood the QL was Sinclair's attempt at a business machine, don't know how much success they had.
Any idea where he got those cases from? I like this plan a lot and thing I might have to try it out;-)
I really need to maintain an offsite backup of my PhD work. The code goes into an online repository anyhow - it's open source. But the rest of my work, my e-mails etc are only backed up locally. It'd be good to have a cost effective way of doing a remote backup.
The bonus relative to buying a USB HDD to keep offsite would be that I could also use a SATA dock to debug broken systems in the future by just extracting their hard drive and shoving it in. Sounds good to me!
AFAIK the 3.5" floppy just drags the head across the disk. Presumably floppies are made of sterner stuff than the Jaz, which was HDD-ish technology. But at the same time, they're low in capacity, slow and die relatively quickly.
I don't know if the low capacity is directly a cost of the head dragging but I bet the slowness and poor reliability are...:-(
OTOH, some tape drives seem to cope quite well at storage capacity and bandwidth whilst still being robust at removable media. I don't know if their heads make contact or not, these days. It's a different deal though since then you lose random access performance. And tape drives always seem to be really expensive:-(
I remember a magazine review where they dropped a "ultra reliable" backup tape into some Guinness to see what would happen - apparently they managed to read the data off! I was pretty impressed at that.
The other main method is to exploit differences between the Red Book standard(audio CDs) and the Yellow Book standard(CDROM drives) and introduce deliberate errors into your CD that will be negligible under redbook but problematic under yellow book.
They used to have CDs out there that simply had a seemingly blank section - about a millimetre or two wide - on the disk. Audio CD players would skip over it without noticing but my Linux PC had issues with it. I guess this would be one of the techniques you described!
It was a funny deal though - some apps would hang trying to read past the "bad" area of the disk in order to get to the last track. cdparanoia was perfectly happy to read every track up to the bad area, which got me all but one track. Not bad...
A friend told me that you could draw over the bad stripe with a CD marker so that it was dark instead of reflective - I had a go at this. It was a bit fiddly because making it too wide obscured bits of valid disk - I had to scrape off some excess with my finger nail.
In the end, it paid off - DRM from a major record label defeated with a marker pen. Those were the "good old days" of DRM when all we needed as weapons were the contents of the supply cupboard!
FWIW, I think those were the CDs that could crash an unpatched anglepoise iMac just by being put into the drive! Evil, evil, evil...
Note this only makes sense in English. In American, the phrase means 'x is trousers,' which is quite nonsensical.
Nope, it's not English versus American.
You're thinking of British versus American. In the English dialect, the correct phrase would be "jolly bad show, old chap" or the alternate form "cor blimey, guv'nor, one is not amused".
The article's question is by no means a silly one, despite what some people on here might think. It's a very valid and relevant concern and it has to do with some fundamental questions of OS design.
One reason that an OS kernel will swap out even when it's not actually forced to do so is because it thinks it can get better overall performance by having something else in the memory instead. You don't have to run out of RAM, just have your OS decide there's something different that would be more useful to have quick access to. So whatever your OS is doing is a strategy that's intended to improve overall throughput in various common cases.
I'm sure there are plenty of replies here already that point this out. I think it's worth noting, though, that optimising for overall throughput - whilst good on a server - is not necessarily best for interactive response times.
Consider the following: every time your CPU switches between tasks, it wastes some processing power. There's an overhead that must be paid in order to do multitasking. Modern OSes interrupt tasks when a timer fires, no matter whether they're still using the CPU - this is the pre-emptive multitasking that makes our interactive experience reliable and (mostly) free of lock-ups. However, since we're interrupting tasks that could have continued to make use of the processor, we're paying a penalty in the overhead required to switch tasks at all. If we'd allowed the task to run until it was complete, or waiting for IO, we'd eliminate that overhead, since the CPU wasn't busy anyhow. We're actually wasting CPU time and therefore reducing throughput (overall work done in the system) in order to achieve a better interactive experience (amongst other things).
Paging in order to make space for caches can be like this. The OS is looking to improve the system's overall efficiency but (depending on what's running) not necessarily the user's interactive experience. For one thing, the OS paging strategy is not even guaranteed to work - it can slow things down if it makes the wrong decision. Secondly, it's not (on a general purpose OS) optimising for interactive experience, it's a compromise between that and throughput. Potentially we're actually damaging our enduser experience by tying ourselves to algorithms that are partially designed to improve throughput on a server-style or mainframe-style workload. Sometimes you actually want to reduce throughput in order to improve user experience; where you draw the line depends on your particular job. Sometimes real-world throughput isn't hurt significantly / at all by improving your response times - the pre-emptible kernel introduced in Linux 2.6, for instance.
Not using swap is and / or using a ramdisk is a hack that shouldn't be necessary if the OS understands and optimises perfectly for the use patterns you're interested in. OSes can't do perfectly in reality and they do a pretty good job. They could still be better, so questions like this are very relevant and are based firmly in reality.
If the facility doesn't seem to be necessary for your usecase, do you really want it? With modern computers, often the answer is still "Yes" but it's still right to ask.
I'm not intending to contradict anything you've said because I agree with it all!
However, thinking of the long term I can remember when the available integrated 2D + 3D graphics cards were a convenient (and cheaper) shortcut but not as good as having separate 2D and 3D cards. I feel old remembering this:-)
I do wonder if the future will produce yet more integration here, though!
Yes, it's not entirely surprising. However, it is a little surprising since this is a rather expensive high security lock with a more complicated key. I guess you could reasonably hope you'd at least need physical access to a key to a high security lock in order to copy it successfully, rather than just seeing it long enough to snap a picture.
I understood that for at least some of the locks there was a key control system that meant that simply copying the strangely-shaped teeth of the key was not enough. However, the addition of a paperclip down one side of the lock was enough to solve that problem:-(
Slashdot Mirror
Yeah but hillbillies want to be called 'Sons of the Soil', but it's never going to happen....
I'm not sure where you're going with that one... Sure, in general usage a language is defined by the whims of the people who speak it. But when it's technical jargon - in this case medical jargon - the technical definition, as opposed to "what everyone calls it" is rather important! I've had friends who call a CRT monitor "the computer", yet my CRT is still unable to function without the part that the geeks refer to as "the computer". Sometimes the commonly used phrase can be technically wrong and therefore misleading, despite the fact that it's popular.
There's also a wider point at stake here: in general, we reserve the right to change the generally accepted meaning of words in the English language (presumably ditto for most other living languages) according to what most people understand them to mean. This typically does not happen in the same way within technical disciplines; physicists draw a distinction between "speed" and "velocity" and show no signs of changing. Usually what terms the techies appropriate to mean something very specific does not affect the rest of us - there's not much point in me labouring the distinction between monitor and computer with my friends, since the misunderstanding doesn't really hurt anyone. This is not the case for medical terminology, where the name of the disease tends to become a label for the sufferers in discussion, as well as a convenient way for a sufferer to explain their condition to an interested third party. The names of diseases have specific technical meanings to a Doctor but are often also used in everyday conversation between people explaining their health situation.
Doctors aren't going to alter the names of diseases just because common usage often confuses a couple of them - it's technical jargon and there's no sense creating confusion in the medical community by changing that around. So it's up to the rest of us: do we want to stick the wrong label on an ill person because it's a generally accepted misunderstanding, or do we attempt to clarify the differences between disorders, knowing that a greater understanding and better use of the terminology is the only way the confusion will ever be resolved.
I'm sticking with the latter approach since it raises public awareness of important issues, even though I know there will always be people who remain confused about the distinction.
NILFS2 (http://www.nilfs.org/en/) is actually a pretty interesting filesystem. It's a log-structured filesystem, meaning that it treats your disk as a big circular logging device.
Log structured filesystems were originally developed by the research community (e.g. see the paper on Sprite LFS here, which is the first example that I'm aware of: http://www.citeulike.org/user/Wombat/article/208320) to improve disk performance. The original assumption behind Sprite LFS was that you'll have lots of memory, so you'll be able to mostly service data reads from your cache rather than needing to go to disk; however, writes to files are still awkward as you typically need to seek around to the right locations on the disk. Sprite LFS took the approach of buffering writes in memory for a time and then squirting a big batch of them onto the disk sequentially at once, in the form of a "log" - doing a big sequential write of all the changes onto the same part of the disk maximised the available write bandwidth. This approach implies that data was not being altered in place, so it was also necessary to write - also into the log - new copies of the inodes whose contents were altered. The new inode would point to the original blocks for unmodified areas of the file and include pointers to the new blocks for any parts of the file that got altered. You can find out the most recent state of a file by finding the inode for that file that has most recently been written to the log.
This design has a load of nice properties, such as:
* You get good write bandwidth, even when modifying small files, since you don't have to keep seeking the disk head to make in-place changes.
* The filesystem doesn't need a lengthy fsck to recover from crash (although it's not "journaled" like other filesystems, effectively the whole filesystem *is* one big journal and that gives you similar properties)
* Because you're not repeatedly modifying the same bit of disk it could potentially perform better and cause less wear on an appropriately-chosen flash device (don't know how much it helps on an SSD that's doing its own block remapping / wear levelling...). One of the existing flash filesystems for Linux (JFFS2, I *think*) is log structured.
In the case of NILFS2 they've exploited the fact that inodes are rewritten when their contents are modified to give you historical snapshots that should be essentially "free" as part of the filesystem's normal operation. They have the filesystem frequently make automatic checkpoints of the entire filesystem's state. These will normally be deleted after a time but you have the option of making any of them permanent. Obviously if you just keep logging all changes to a disk it'll get filled up, so there's typically a garbage collector daemon of some kind that "repacks" old data, deletes stuff that's no longer needed, frees disk space and potentially optimises file layout. This is necessary for long term operation of a log structured filesystem, though not necessary if running read-only.
Another modern log structured FS is DragonflyBSD's HAMMER (http://www.dragonflybsd.org/hammer/), which is being ported to Linux as a SoC project, I think (http://hammerfs-ftw.blogspot.com/)
unless you believe in the possibility of some magic side-effect whereby the processor is slowed down because you're using a different filesystem. (It's just about possible, e.g. if the filesystem gobbles lots of memory and causes your machine to thrash, but in the real world it's a waste of time running these things.)
Some filesystems have higher CPU usage - aside from issues of data structure complexity, btrfs does a load of extra checksumming, for instance.
But your point stands that CPU-bound benchmarks are probably not the best way of measuring a filesystem. It would be interesting to measure CPU usage whilst running a filesystem-intensive workload, or even to measure this indirectly through the slowdown of bzip2 compression whilst running a filesystem-intensive workload in the background.
Should that Giant Magnetoresistive? Someone else seems to so because the article is tagged "typoinsummary". Google and I haven't heard much about Great Magnetoresistive effect in the past, so unless it's some obscure term...
But hey, it's not my area of expertise and I certainly agree that with the sentiment that this magnetoresistive stuff is rather great!
Argh, so I'm turning into the kind of person who comments without reading *either* article in question but ...
Last time this came up, plenty of people pointed out that the G1 garbage collector was available to anyone, Open Source but that it was in development and you weren't recommended to use it in production without a support contract. A number of people even pointed out the settings that anybody could change to enable the experimental G1 garbage collector on their own system.
Perhaps this is case of adjusting their wording to make it easier for Slashdot to not report incorrectly ;-)
eep eep eep!
Dude, the Go-Bots were awesome!
If anyone moderates this funny I shall be offended :-p
"the real competition between the Zune HD and the iPod Touch will come down to software. The new Zune will be based on a custom version of Windows CE, while the iPod Touch runs on the already popular iPhone platform, for which thousands of applications are available"
So the main weakness of the Microsoft platform is that very little popular software appears to be available for it, whereas the Apple equivalent is where all the apps are ... If anybody fell asleep a few years ago and woke up to this they are going to be very confused!
I'd say this is simultaneously an example of:
a) how if MS produce a platform that many users prefer - like Apple originally did with the iPhone - that the application builders Will Come.
b) just what an incredible job Apple's simultaneous technical and marketing pushes have done for their entry into the phone market.
It'll be interesting to see what trends emerge for MS and Apple in the future.
When I go into my local butchers, sometimes the radio is on. The butchers have to buy a license from the PRS - there's a letter on the wall certifying that they have, in fact, paid for the license to play radio in public. If people were going "Oh, I don't really want any bacon today ... hmmm, I do really dig the music at the butchers, though! Lets go anyhow ..." then perhaps it would be a *little* understandable (though not necessarily reasonable) that PRS wanted a share of the profits. But I really really don't think people are going to the butcher to listen to music and party amongst the cold meats. In any case I can already listen to the same stuff on my own radio!
Perhaps whilst they're reducing their rates the PRS could relax some of their more ridiculous rules about public listening and then I can afford (marginally) more bacon. Om nom nom nom.
[Citation Needed]
The Pandora people have posted plenty of pictures and videos of their prototypes, working units, production samples, etc to demonstrate that their project is real.
There was a Linux-based console that turned out to be a scam recently but it wasn't the Pandora. Perhaps you are thinking of that?
As for running KDE apps, e.g. Okular on Windows, they're not running an entire desktop under Windows, you're running one app that uses a cross-platform toolkit. If you use Firefox or Opera you would also be using a cross-platform toolkit, rather than simply native Windows APIs.
You could probably argue that having all the KDE goop is overkill but it's still not quite the same as running a whole desktop, which would suggest to me a separate taskbar, filemanager, menu, etc and no integration with the rest of Windows. AFAIK KDE apps for Windows run quite happily as individual apps, no need to start up the rest of the desktop.
My experience of Okular (and its predecessor, kpdf) is that it's quite fast to render, much faster to start than Adobe's own readers typically are, integrates nicely with my desktop (tbf I'm using KDE so you'd expect it to). My work involves reading a lot of PDF's, so Okular is a KDE4 killer app. As a result I've not installed Adobe's reader on this machine in ages. If I used Windows / Mac more I'd definitely want it on those platforms too!
You can probably use Okular via the KDE for Windows port, though I don't know if that's had an official stable release yet; don't really use Windows much, otherwise I'd look into it more since in my experience it's a nice app than Adobe's offerings tend to be, whilst still being fast and featureful.
Okular might well work on MacOS X via the KDE for Mac stuff - same caveats but I don't own a Mac so I've *never* tried this ;-)
It's funny - when people talk about Linux being hard to use nowadays I think back to myself as a gaming-hungry young teenager with no formal computer training. I would busily pack the minimum essential drivers as efficiently as possible into RAM so that sound and the cool joystick animations would work in Wing Commander 2. I wasn't doing it to tinker, it was just the way we used PCs. A different OS configuration for each individual game and another one entirely for Windows. Nice.
Every so often I step back and think that being able to run multiple apps *at once* without rebooting into effectively a different OS is a lot more user friendly than how I started out in PCs ;-)
To be fair, the MS-DOS memory management fiddling was also more painful than my Sinclair Spectrum machines - they loaded software off squealing tape drives but at least software worked out of the box (usually). But I digress...
Anyhow, he showed us a picture of himself standing next to The First Hard Drive (cue angelic chorus) as demonstrated by IBM. It was about as tall as a man, the platters were exposed to view and there was (IIRC) only one head, which looked like a big robot arm. To read from different platters it pulled out of the assembly, moved up and down, then moved into the drive again. Unbelievable that they've become so tiny and intricate. IIRC (I'm probably a bit off!) that first drive had a capacity of about a megabyte or so.
Maurice Wilkes is also credited as the first person recorded as suggesting the idea of the "subroutine". According to Wikipedia, he also came up with the ideas of symbolic labels and macros. Must have been amazing to do such fundamental work and then be able to see the field develop as it has now!
One of the computers he built had a "Stop machine and ring bell for operator attention" so I guess not every thing that he did has become fundamental to our field... merely many of them ;-)
For the QL they upped the storage capacity on the microfloppies by .... changing the speed of the drive motor! Hurrah for old tech ;-)
I saw a picture somewhere of an old mainframe / minicomputer with approximately a giant version of the Sinclair microfloppy technology - it just looked like a big box with a pile of tape in it and the two ends of the tape going out the top of the box to the head. Seeing that, I could understand how my little microfloppy drive used to munch up the cartridges (so cute, though!).
I went to a lecture on the QL only a few years ago by my local computer preservation society. Apparently it had a windowed interface and a pre-emptively multitasking OS - took PCs years (decades even, depending on if you were a home user!) to catch up. I understood the QL was Sinclair's attempt at a business machine, don't know how much success they had.
I really need to maintain an offsite backup of my PhD work. The code goes into an online repository anyhow - it's open source. But the rest of my work, my e-mails etc are only backed up locally. It'd be good to have a cost effective way of doing a remote backup.
The bonus relative to buying a USB HDD to keep offsite would be that I could also use a SATA dock to debug broken systems in the future by just extracting their hard drive and shoving it in. Sounds good to me!
AFAIK the 3.5" floppy just drags the head across the disk. Presumably floppies are made of sterner stuff than the Jaz, which was HDD-ish technology. But at the same time, they're low in capacity, slow and die relatively quickly. I don't know if the low capacity is directly a cost of the head dragging but I bet the slowness and poor reliability are... :-(
OTOH, some tape drives seem to cope quite well at storage capacity and bandwidth whilst still being robust at removable media. I don't know if their heads make contact or not, these days. It's a different deal though since then you lose random access performance. And tape drives always seem to be really expensive :-(
I remember a magazine review where they dropped a "ultra reliable" backup tape into some Guinness to see what would happen - apparently they managed to read the data off! I was pretty impressed at that.
The other main method is to exploit differences between the Red Book standard(audio CDs) and the Yellow Book standard(CDROM drives) and introduce deliberate errors into your CD that will be negligible under redbook but problematic under yellow book.
They used to have CDs out there that simply had a seemingly blank section - about a millimetre or two wide - on the disk. Audio CD players would skip over it without noticing but my Linux PC had issues with it. I guess this would be one of the techniques you described!
It was a funny deal though - some apps would hang trying to read past the "bad" area of the disk in order to get to the last track. cdparanoia was perfectly happy to read every track up to the bad area, which got me all but one track. Not bad...
A friend told me that you could draw over the bad stripe with a CD marker so that it was dark instead of reflective - I had a go at this. It was a bit fiddly because making it too wide obscured bits of valid disk - I had to scrape off some excess with my finger nail.
In the end, it paid off - DRM from a major record label defeated with a marker pen. Those were the "good old days" of DRM when all we needed as weapons were the contents of the supply cupboard!
FWIW, I think those were the CDs that could crash an unpatched anglepoise iMac just by being put into the drive! Evil, evil, evil...
Note this only makes sense in English. In American, the phrase means 'x is trousers,' which is quite nonsensical.
Nope, it's not English versus American. You're thinking of British versus American. In the English dialect, the correct phrase would be "jolly bad show, old chap" or the alternate form "cor blimey, guv'nor, one is not amused".
One reason that an OS kernel will swap out even when it's not actually forced to do so is because it thinks it can get better overall performance by having something else in the memory instead. You don't have to run out of RAM, just have your OS decide there's something different that would be more useful to have quick access to. So whatever your OS is doing is a strategy that's intended to improve overall throughput in various common cases.
I'm sure there are plenty of replies here already that point this out. I think it's worth noting, though, that optimising for overall throughput - whilst good on a server - is not necessarily best for interactive response times.
Consider the following: every time your CPU switches between tasks, it wastes some processing power. There's an overhead that must be paid in order to do multitasking. Modern OSes interrupt tasks when a timer fires, no matter whether they're still using the CPU - this is the pre-emptive multitasking that makes our interactive experience reliable and (mostly) free of lock-ups. However, since we're interrupting tasks that could have continued to make use of the processor, we're paying a penalty in the overhead required to switch tasks at all. If we'd allowed the task to run until it was complete, or waiting for IO, we'd eliminate that overhead, since the CPU wasn't busy anyhow. We're actually wasting CPU time and therefore reducing throughput (overall work done in the system) in order to achieve a better interactive experience (amongst other things).
Paging in order to make space for caches can be like this. The OS is looking to improve the system's overall efficiency but (depending on what's running) not necessarily the user's interactive experience. For one thing, the OS paging strategy is not even guaranteed to work - it can slow things down if it makes the wrong decision. Secondly, it's not (on a general purpose OS) optimising for interactive experience, it's a compromise between that and throughput. Potentially we're actually damaging our enduser experience by tying ourselves to algorithms that are partially designed to improve throughput on a server-style or mainframe-style workload. Sometimes you actually want to reduce throughput in order to improve user experience; where you draw the line depends on your particular job. Sometimes real-world throughput isn't hurt significantly / at all by improving your response times - the pre-emptible kernel introduced in Linux 2.6, for instance.
Not using swap is and / or using a ramdisk is a hack that shouldn't be necessary if the OS understands and optimises perfectly for the use patterns you're interested in. OSes can't do perfectly in reality and they do a pretty good job. They could still be better, so questions like this are very relevant and are based firmly in reality.
If the facility doesn't seem to be necessary for your usecase, do you really want it? With modern computers, often the answer is still "Yes" but it's still right to ask.
I heard that Star Trek sometimes features unrealistic physics and that Jedi isn't a real religion. What is it with the world these days?
I'm not intending to contradict anything you've said because I agree with it all! However, thinking of the long term I can remember when the available integrated 2D + 3D graphics cards were a convenient (and cheaper) shortcut but not as good as having separate 2D and 3D cards. I feel old remembering this :-)
I do wonder if the future will produce yet more integration here, though!
Yes, it's not entirely surprising. However, it is a little surprising since this is a rather expensive high security lock with a more complicated key. I guess you could reasonably hope you'd at least need physical access to a key to a high security lock in order to copy it successfully, rather than just seeing it long enough to snap a picture. I understood that for at least some of the locks there was a key control system that meant that simply copying the strangely-shaped teeth of the key was not enough. However, the addition of a paperclip down one side of the lock was enough to solve that problem :-(
Item(s):
An Illustrated History of Anthropology
Price (dollars):
Many