Yep. Robert Heinlein's novel The Moon is a Harsh Mistress features an excellent description of a lunar colony revolution where the "lunies" break away from Earth by "throwing rocks".
When it's conventionally taped, don't you skip the commercials as well?
Yes - but only if you recorded the show with your VCR. It isn't so much the mechanics of being able to fast-forward through commercials that is significant about PVR technology - the significant thing is the change in viewing and recording habits that it tends to bring about.
Recording stuff with a conventional tape based VCR
is a pain (finding a tape to record on, making a note of which tapes have what on, keeping track of which tapes can be re-used, programming the timer, putting the recorder into timer-record-mode, not being able to use the recorder for anthing else - such as playback - once you've set it up to record something). VCR time shifting tends to be used for shows that you really want to see, but can't be in front of the TV set for, or which clash with other programming that you really want to see - it is a mechanism for handling exceptions.
Recording stuff with PVR with built in program guide, wishlists, season passes, suggestions, etc, is actually easier than remembering to watch the shows that you are interested in on live TV, at particular times, on particular days. Once you have got used to it, PVR time shifting tends to be the preferred form for scheduling and watching TV. Experience suggests that TiVo users tend to stop watching live TV and time shift nearly everything - even stuff that they could have watched live if they had wished to.
PVR viewers are therefore in a position to ad-skip during almost all of their TV viewing.
NSS (name service switch) provides "on the fly" reconfigurable name services - it is the mechanism that allows (for example) a Solaris or Linux machine to look up password entries in/etc/passwd, the NIS, LDAP, or whatever, depending on the contents of the "passwd:" line of/etc/nsswitch.conf.
NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.
A system where some of the binaries obey preferences the admin expresses through/etc/nsswitch.conf but, say,/bin/lsdoesn't is unlikely to be popular!:-)
I was under the impression that OS X was _A_ BSD but not actually a code fork of FreeBSD. Do
they really share the same code in the base distribution? Or are they just cousins in the same family
tree?
IIRC, the kernel is Mach micro-kernel running
a BSD personality layer, and the userland is a
code-fork from FreeBSD 3.2
I've worked in a number of large Solaris shops, and never ONCE has a Sun sales droid or FE/SE asked about licenses. We spend $$$ on systems and support contracts; they dont bicker about petty things like per-CPU licenses for the operating system.
If you're paying for a support contract on a box then that includes Solaris upgrades.
I fail to see what the big hoopla is about, or why this is even posted to Slashdot. After all, this isn't even the first time that this has happened.
It is the first time it happened to UK TiVo
users, and TiVo UK bungled: they didn't tell
the users that it was coming.
It has been something of a public relations disaster, because a lot of the UK users felt a
sudden and unexpected loss of control when their
TiVo boxes exibited changed behaviour without user intervention or notification from TiVo.
While it is true that an "enhanced content" recording doesn't consume space in the main recording area of a TiVo, this first use of the feature has opened many people's eyes to the fact that there is the best part of an hour's worth of disk space on an unexpanded UK TiVo which is reserved for supporting this sort of thing.
Also, the fact that the BBC picked a complete episode of a crap sitcom to pilot the "enhanced content" feature with is unlikely to go down well with TiVo's techy, early adopter audience!
The main reason why you run into multiple incompatible mechanisms in software like Emacs is that the software started as a TTY application, and only gained an X interface later (and in the case of Emacs in particular, the fact that it still works independent of X if X isn't available).
I can to Ctrl-k ctrl-y to cut and paste in Xemacs, but it doesn't work across different xemacs windows.
It sounds to me as though you are starting multiple independent instances of Xemacs to edit multiple files - I don't know Xemacs, but speaking as a GNU Emacs user, I think that you will find that running a single Emacs process and opening multiple "frames" to edit multiple buffers is the correct way to go.
It isn't quite the GUI-less daemon that you describe, but the xclipboard utility might be of interest.
How long before the Linux kernel is forked by someone that actually does version management with CVS?
It will happen if and when "someone" decides get on and do it (and if enough people flock to their banner to use, and contribute to, the resulting software).
Don't let us stand in your way: "Show us the code".:-)
Hasn't anyone figured out Red Hat's release schedule yet? Like clockwork, April
and October. Every six months, a new release. Downloading ISOs after August or
February is a waste of time...
And this is (contrary to what is said by the
original poster) about half the rate of FreeBSD
releases, where releases are normally cut from the STABLE branch quarterly.
The point of the "anti-trust thing" was that
Microsoft gave away IE in order to destroy Netscape Navigator. The reason for wanting to destroy Netscape Navigator was to eliminate the possiblity that Navigator might evolve into an OS neutral platform for providing applications to end users. This would undermine the Windows OS monopoly, depriving Microsoft of the many sales that they get not because people actually want Windows per se, but because they *must* have Windows in order to run the applications that they need for their work, run the latest cool game, or whatever (this effect is what Judge Jackson calls "the applications barrier to entry" to the OS market place).
The OS monopoly allows Microsoft to charge basically whatever they like for Windows - it is priced far higher than it would be if it had to compete on a level playing field with other operating systems software.
Re:Alan Cox diving under a rock?
on
MAPS vs. ORBS
·
· Score: 1
The diary also tells us that he's recently moved into a house that requires a lot of work doing on it. Even demi-gods are allowed to have a life outside of Linux, surely?:-)
Re:Questions about DeCSS
on
DeCSS Update
·
· Score: 1
Wouldn't it be perfectly legal for, say, a no-name electronics manufacturer to reverse engineer a hardware DVD player in order to create a compatible DVD player to sell to the market?
You might think so - but this is exactly the kind of thing that CSS is designed to try and prevent!
Personally, i think it kicks ass when it comes to ease of use, performance and stability, and it sucks when it can't boot a partition beyond cylinder 1024. So i can't actually use it now. Must get rid of that FAT32 kludge that sits in front of my disk first. And UNIX is supposed to be older technology than DOS...
To be fair, that is a limitation with the BIOS, rather than with FreeBSD.
Now they announce the 4.0 freeze just one week after I shelled out $39.95 for 3.4. I guess it's time to subscribe...
The 4.0 isn't necessarily the upgrade path from 3.4. 4.0 is a release from the CURRENT branch, whereas 3.4 is a release from the STABLE branch. Unless you really want to be on the cutting edge, or you really need a facility that is only in CURRENT, then it probably makes sense to stay with STABLE for the moment.
Is Microsoft really as bad as everyone makes out. Sure it is fun to bag them for money hungry, heartless bean counters that make crap products. But it must be remembered that a lot of there products have brought the masses (for better or worse) easy *sic* to operate computers with easy to use software.
IMHO, yes, they are every bit as bad as their opponents make out. All this stuff about "inovation" and bringing "easy" computing to the masses is PR crap.
Their stuff doesn't work. Trying to support their awful non-functional OS and their truly dreadful, buggy, bloated applications is the worst aspect of any decent sized IT operation. And there is no alternative, because much of the user population is locked into applications and file formats which they can only work with under Windows. Microsoft use their monopoly power to keep things this way (them rich, anyone who wants to do something truely different marginalized, and me and countless other people who care about the "Right Thing" miserable!). That is what the anti-trust case is about.
In the early versions of Unix, there was a hack in CC so that if someone compiled a kernel, it would insert a backdoor so Ken Thompson could log into any Unix machine! Not only that, but it could also detect if the compiler was compiling itself so it could add the backdoor-producing code into the new compiler.
This hack get a vote from me, too. One correction: as I recall the story it was "login.c" that the compiler backdoored, rather than the kernel.
Traditionally, the Berkeley Fast File System (which is what most Unix file systems are based on these days), has written "meta-data" (directory entries, the stuff in inodes and superblocks, etc) in a synchronous fashion. That is: when write to filesystem meta-data is required then the the system goes straight to the physical disk drive with the changes and updates disk blocks. This differs from the way that the system handles straight data writes, where the write may just go into a memory buffer for later asynchronous write-out to physical disk.
ext2fs, in default configuration, uses asynchronous writes for meta-data as well as for data. This gives a useful speedup (particularly in operations like creating/deleting directories and stuff like "ls -l" in a big directory, which updates the atime on each inode of every file). It also means that if the system panics or you have a power outage there is a bigger chance of there being meta-data critical to the file system structure which is hanging around in RAM and which hasn't been committed to the physical disk.
I've seen quotes from Linus on this that say, effectively, "but Linux doesn't crash anyway". This is cute, but doesn't help much if the power company messes you around, or if a clueless user manages to push the Big Red Button on your main server...
The "safety" thing tends to be brought up by BSD types (like myself:-)) when people make unfavourable comparisons between the speed of BSD filesystem operations compared with Linux filesystem operations. At the end of the day it is a trade off between speed and crash hardening (and you can run either system either way: both systems have mount options to do sync or async meta-data updates, its just that BSD defaults sync and Linux defaults async).
In the BSD world, async mounts tend to be seen as a performance hack which is justified for a filesystem that you wouldn't mind loosing in the event of a crash - a news spool, perhaps, a filesystem to which you are currently installing, or restoring from backup (if it stuffs up you can just start over without file loss) or/usr/obj (where BSD stashes.o files during a system recompile). I've seen it suggested that the structure of ext2fs is such that filesystem corruption is less of a problem/easier to repair anyway, so ext2fs users may well be justified in having a different take on the tradeoff from BSD users.
The good news is that, with softupdates in BSD, and various log based filesystems beginning to appear in Linux, both camps are now able to "have their cake and eat it" (or will be able to soon enough).
I got the impression that the BBC Online "article" is basically just a teaser for the broadcast interview on Sunday... as written it's a very general and woolly overview.
Hopefully Paxo will be on form when we get to see the real thing.:-)
Abduct the sender and start cutting fingers off until he gives up the pass phrase to his private key.
Which is, of course, why PGP users shouldn't use the "encrypt to self" option if they are operating in a hostile environment.
If the sender is using a public key crypto system and encrypts the session key with only the recipient's public key (and not their own) then you're going to have to find and torture the recipient.
Slashdot Mirror
Yep. Robert Heinlein's novel The Moon is a Harsh Mistress features an excellent description of a lunar colony revolution where the "lunies" break away from Earth by "throwing rocks".
Yes - but only if you recorded the show with your VCR. It isn't so much the mechanics of being able to fast-forward through commercials that is significant about PVR technology - the significant thing is the change in viewing and recording habits that it tends to bring about.
Recording stuff with a conventional tape based VCR is a pain (finding a tape to record on, making a note of which tapes have what on, keeping track of which tapes can be re-used, programming the timer, putting the recorder into timer-record-mode, not being able to use the recorder for anthing else - such as playback - once you've set it up to record something). VCR time shifting tends to be used for shows that you really want to see, but can't be in front of the TV set for, or which clash with other programming that you really want to see - it is a mechanism for handling exceptions.
Recording stuff with PVR with built in program guide, wishlists, season passes, suggestions, etc, is actually easier than remembering to watch the shows that you are interested in on live TV, at particular times, on particular days. Once you have got used to it, PVR time shifting tends to be the preferred form for scheduling and watching TV. Experience suggests that TiVo users tend to stop watching live TV and time shift nearly everything - even stuff that they could have watched live if they had wished to.
PVR viewers are therefore in a position to ad-skip during almost all of their TV viewing.
NSS (name service switch) provides "on the fly" reconfigurable name services - it is the mechanism that allows (for example) a Solaris or Linux machine to look up password entries in /etc/passwd, the NIS, LDAP, or whatever, depending on the contents of the "passwd:" line of /etc/nsswitch.conf.
NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.
A system where some of the binaries obey preferences the admin expresses through /etc/nsswitch.conf but, say, /bin/ls doesn't is unlikely to be popular! :-)
Probably 'cos of his involvement as a primary developer of XEmacs and Netscape Navigator 1.x and 2.x.
IIRC, the kernel is Mach micro-kernel running a BSD personality layer, and the userland is a code-fork from FreeBSD 3.2
If you're paying for a support contract on a box then that includes Solaris upgrades.
It is the first time it happened to UK TiVo users, and TiVo UK bungled: they didn't tell the users that it was coming.
It has been something of a public relations disaster, because a lot of the UK users felt a sudden and unexpected loss of control when their TiVo boxes exibited changed behaviour without user intervention or notification from TiVo.
While it is true that an "enhanced content" recording doesn't consume space in the main recording area of a TiVo, this first use of the feature has opened many people's eyes to the fact that there is the best part of an hour's worth of disk space on an unexpanded UK TiVo which is reserved for supporting this sort of thing.
Also, the fact that the BBC picked a complete episode of a crap sitcom to pilot the "enhanced content" feature with is unlikely to go down well with TiVo's techy, early adopter audience!
StrawberryFrog asked:
The main reason why you run into multiple incompatible mechanisms in software like Emacs is that the software started as a TTY application, and only gained an X interface later (and in the case of Emacs in particular, the fact that it still works independent of X if X isn't available).
It sounds to me as though you are starting multiple independent instances of Xemacs to edit multiple files - I don't know Xemacs, but speaking as a GNU Emacs user, I think that you will find that running a single Emacs process and opening multiple "frames" to edit multiple buffers is the correct way to go.
It isn't quite the GUI-less daemon that you describe, but the xclipboard utility might be of interest.
Jamie Zawinski's notes on how Selections, Cut Buffers, and Kill Rings are supposed to work on X might also be interesting to you.
It will happen if and when "someone" decides get on and do it (and if enough people flock to their banner to use, and contribute to, the resulting software).
Don't let us stand in your way: "Show us the code". :-)
And this is (contrary to what is said by the original poster) about half the rate of FreeBSD releases, where releases are normally cut from the STABLE branch quarterly.
Target date for FreeBSD 4.5: 15th January 2002.
Anonymous Coward asked:
Err - no.
HTH.
Yes. :-)
The point of the "anti-trust thing" was that Microsoft gave away IE in order to destroy Netscape Navigator. The reason for wanting to destroy Netscape Navigator was to eliminate the possiblity that Navigator might evolve into an OS neutral platform for providing applications to end users. This would undermine the Windows OS monopoly, depriving Microsoft of the many sales that they get not because people actually want Windows per se, but because they *must* have Windows in order to run the applications that they need for their work, run the latest cool game, or whatever (this effect is what Judge Jackson calls "the applications barrier to entry" to the OS market place).
The OS monopoly allows Microsoft to charge basically whatever they like for Windows - it is priced far higher than it would be if it had to compete on a level playing field with other operating systems software.
The diary also tells us that he's recently moved :-)
into a house that requires a lot of work doing
on it. Even demi-gods are allowed to have a life
outside of Linux, surely?
You might think so - but this is exactly the kind of thing that CSS is designed to try and prevent!
To be fair, that is a limitation with the BIOS, rather than with FreeBSD.
The 4.0 isn't necessarily the upgrade path from 3.4. 4.0 is a release from the CURRENT branch, whereas 3.4 is a release from the STABLE branch. Unless you really want to be on the cutting edge, or you really need a facility that is only in CURRENT, then it probably makes sense to stay with STABLE for the moment.
The client shouldn't infer the type of the object based on an "extension" in the URL at all ... that is what the Content-Type header is for!
BigTed asks:
IMHO, yes, they are every bit as bad as their opponents make out. All this stuff about "inovation" and bringing "easy" computing to the masses is PR crap.
Their stuff doesn't work. Trying to support their awful non-functional OS and their truly dreadful, buggy, bloated applications is the worst aspect of any decent sized IT operation. And there is no alternative, because much of the user population is locked into applications and file formats which they can only work with under Windows. Microsoft use their monopoly power to keep things this way (them rich, anyone who wants to do something truely different marginalized, and me and countless other people who care about the "Right Thing" miserable!). That is what the anti-trust case is about.
Kinthelt wrote:
This hack get a vote from me, too. One correction: as I recall the story it was "login.c" that the compiler backdoored, rather than the kernel.
Traditionally, the Berkeley Fast File System (which is what most Unix file systems are based on these days), has written "meta-data" (directory entries, the stuff in inodes and superblocks, etc) in a synchronous fashion. That is: when write to filesystem meta-data is required then the the system goes straight to the physical disk drive with the changes and updates disk blocks. This differs from the way that the system handles straight data writes, where the write may just go into a memory buffer for later asynchronous write-out to physical disk.
ext2fs, in default configuration, uses asynchronous writes for meta-data as well as for data. This gives a useful speedup (particularly in operations like creating/deleting directories and stuff like "ls -l" in a big directory, which updates the atime on each inode of every file). It also means that if the system panics or you have a power outage there is a bigger chance of there being meta-data critical to the file system structure which is hanging around in RAM and which hasn't been committed to the physical disk.
I've seen quotes from Linus on this that say, effectively, "but Linux doesn't crash anyway". This is cute, but doesn't help much if the power company messes you around, or if a clueless user manages to push the Big Red Button on your main server ...
The "safety" thing tends to be brought up by BSD types (like myself :-)) when people make unfavourable comparisons between the speed of BSD filesystem operations compared with Linux filesystem operations. At the end of the day it is a trade off between speed and crash hardening (and you can run either system either way: both systems have mount options to do sync or async meta-data updates, its just that BSD defaults sync and Linux defaults async).
In the BSD world, async mounts tend to be seen as a performance hack which is justified for a filesystem that you wouldn't mind loosing in the event of a crash - a news spool, perhaps, a filesystem to which you are currently installing, or restoring from backup (if it stuffs up you can just start over without file loss) or /usr/obj (where BSD stashes .o files during a system recompile). I've seen it suggested that the structure of ext2fs is such that filesystem corruption is less of a problem/easier to repair anyway, so ext2fs users may well be justified in having a different take on the tradeoff from BSD users.
The good news is that, with softupdates in BSD, and various log based filesystems beginning to appear in Linux, both camps are now able to "have their cake and eat it" (or will be able to soon enough).
I got the impression that the BBC Online "article" is basically just a teaser for the broadcast interview on Sunday ... as written it's a very general and woolly overview.
Hopefully Paxo will be on form when we get to see the real thing. :-)
An AC wrote:
Which is, of course, why PGP users shouldn't use the "encrypt to self" option if they are operating in a hostile environment.
If the sender is using a public key crypto system and encrypts the session key with only the recipient's public key (and not their own) then you're going to have to find and torture the recipient.