FreeBSD's "portupgrade" system is able to find, build, install, and resolve conflicts in both source and binary distributions of FreeBSD ports/packages even with a moving target of a source tree, with full potential for overrides and magic.
I use it constantly for system maintainence; it fits the Source-based BSD philosophy beautifully, the way APT fits Debian's Binary-package-based orientation.
The only thing that keeps it from being in the base install is that it requires Ruby.
The file formats developed cover both compressed and uncompressed transmission of scent: Nosepeg and.WIF
Re:The problem is manned space-flight of any kind
on
NASA's Own X Prize?
·
· Score: 1
This argument rests on the assumption that the entire objective is to advance science by providing new practical avenues to justify fundamental research (especially in the field of material science).
If, however, you also want to inspire another generation, and move people's hearts toward space exploration, then every politico knows that the Big Event is where it's at. It's not just the press who aren't interested in football-sized probes. Generally, people aren't cold utilitarians.
Also, given the high level of short interest in SCOX, that you have enough cash to cover a margin call during the short squeeze that's certain to occur.
(my layman's understanding of the situation: the short squeeze occurs when people start to cash in their short positions, jacking the price *up* for a very short term because, by definition, you have to buy the stock to close the short position.
If you can't cover the margin call during the squeeze, you may be forced to buy above your selling price, thus *losing* you money. The stock generally plunges shortly afterwards)
You could just install FreeBSD and then the Debian port. You can then chroot into a Debian jail. Looks like Debian, smells like Debian, but the kernel is FreeBSD. Would that do?:)
I've built Linux kernels inside Debian jails on FreeBSD and they're binary identical (as I would have expected, but it was nice to see it work).
rsync'ing in Portage is not hardcoded to use CVS - it can sync trees originated/exported from any other versioning system too.
You can make that statement of CVSUp and it will still be true. CVSUp simply has extra support for CVS repositories to make the deltas smaller. For non-CVS data repositories, CVSUp uses rsync/append/copy algorithms as appropriate.
In practice, my experience with CVSUp is that it makes an excellent tool for regularly synchronising fixed repositories specific to an application, and rsync more ideal for sync'ing ad-hoc data.
In particular, I have (at work) a multilevel CVSUp hierarchy distributing large amounts of data internationally and it's been flawless in operation.
"Professor Fels was appointed as Professor of Administration at Monash University in 1984 and was the Director of the Graduate School of Management, Monash University from 1985 until 1990 and is now an Honorary Professor in the Faculty of Business and Economics at Monash University."
Forgot to paste in; of course, also RFC 1034 (section 3.3), published in 1987.
The patent itself is effectively fraud. Most of the document is occupied with long-winded noise designed to disguise the claim in a torrent of drivel by describing, in excruciatiating, irrelevent and confusingly-numbered detail, a webmail and fax system. The claim itself is only tangentially related to what is written.
Stealing the ideas in a decades-old technical standard? This is yet another embarrassing failure by the USPTO.
- J
At least one specific recommendation by a governing body for using hostmaster.example.com. as a DNS label to represent "hostmaster@example.com" can be found here, published well before this patent was filed.
This can also be seen in RFC 1912 (section 2.2), published in 1996.
These muppets have patented something published in one of the very standards they should be familiar with.
Er, your research is a Wired article and a three-year-old report on the proceedings of a quango conference subcomittee.
Did you read the amendment, the Additional Protocol? It's
here.
Notes for discussion as to whether or not this actually "bans ideas":
The amendment to the convention on cybercrime does not impact on the "wide swathe of ideas" you claim. On the contrary, it's very narrow, and relates primarily to criminal intent.
To summarise more precisely: the amendment requires ratifying nations to create an offence of "distributing, or otherwise making available" material which "advocates, promotes or incites hatred, discrimination or violence".
This is repression of expression. It is a restriction on the freedom of expression. For sure. However, to quote your article:
We're looking for things we can't say that are true, or at least have enough chance of being true that the question should remain open.
I argue that incitement to hatred, violence and discrimination is not truth. It is true that those concepts and acts, and their corresponding acts of incitement exist, but they have no intrinsic truth of themselves.
Inciting hatred and violence barely qualifies as an idea, except inasmuch as it can be described; in practice, it's more of an act, similar to criminal acts of conspiracy. As the notes provided on the amendment say,
13. The definition contained in Article 2 of this Protocol refers to certain conduct to which the content of the material may lead, rather than to the expression of feelings/belief/aversion as contained in the material concerned.
The language "advocates, promotes or incites" is very important. Can I put this more clearly? An example of what is outlawed by this measure might be the statement "Go out and kill Americans, and I will give you some money". This is not an idea; it is an instruction, an act of conspiracy.
Since you're fond of digging up old articles, here's one more, from 1997, which says:
The Dutch government will not be adopting a law in the near future making Holocaust denial a criminal offense. According to the left-wing liberal Justice Minister Winnie Sorgrdrager, the law would not be an effective means to fight against "false and tasteless opinions." At the same time, the justice minister expressed her concern about the revival of fascist ideology in Europe.
The Additional Protocol does not require the denial of the Holocaust, which however vile and distasteful does qualify as an idea that we may sometimes be forced to discuss, to be an offence (Article 6.2 is the get-out clause).
Now, under Dutch law, incitement to hatred is already a criminal offence, and denying the Holocaust in certain ways has been interpreted judicially as falling under that legislation. (Holocaust denial is almost invariably an incitement to aggressive neo-Nazi groups).
So perhaps I will revise my statement and put it in context. There is nothing you can't say, but if you harm others with your statements - through incitement to violence, or discrimination - then you may be liable.
Let's start with a test: Do you have any opinions that you would be reluctant to express in front of a group of your peers?
I don't, but that's not because I or my peers are conformist. Having offered conformism as a likely inference and dismissed coincidence as unlikely, Graham leaves out a third possibility: that my peer group is by habit and nature nonconformist and will happily accept and discuss any stated opinion.
The fourth possibility is that Graham means people of my age and cultural background (i.e. Greco-Roman/Anglo-Saxon derived Caucasian), rather than those folk I actually regard as a peer group. I profoundly resent the immediate derivation Graham makes - that "everything you believe is something you're supposed to believe". There are no grounds for reaching this conclusion from the position of lack of fear of wide-reaching discussion and candidness.
This article is a fine piece of fluff, with the low-flying non sequiturs carefully balanced by the empty speculation. Here's another example:
And yet, I wonder. The Dutch seem to live their lives up to their necks in rules and regulations. There's so much you can't do there; is there really nothing you can't say?
Perhaps Mr Graham should actually do some research before he wonders out loud. I lived in the Netherlands for two years, and the answer is yes. There is nothing you can't say. Next question. There's plenty you can't do because astoundingly even the Dutch would prefer not to sponsor murder, child molestation, or deviation from proper procedure.
Woolly thinking and a few historical quotations do not a strong argument make.
It's also a mind-boggling claim that an open architecture was a mistake in the Internet's design. By levelling the field of experimentation, the result has surely being a skyrocketing success.
You can certainly throw together an experimental IP network in your garage with cheap third-hand gear from ebay, swapmeets etc (e.g. old PCs running a free OS, old cisco routers).
Now try simulating a circuit-switched telco network. Not so easy.
When the Junior Unix Sysadmin comes to me, as they do, and asks "what language should I write this tool in?", here is my decision sequence:
shell (with sed/awk/grep) for process management/job control and line-by-line text processing.
C for servers, time-sensitive applications, interfaces to syscalls.
Python or Ruby for complex system tools that benefit from an object model.
Perl for text mangling. I know; Perl can do anything, and often it's the fastest to write. But as the corollary has it: in Perl, there are too many ways to do it. I usually say that "Using Perl for any of the above is cheating," but what I actually mean is that since most of the perl I've seen produced by anyone below "Guru" status is sloppy, undisciplined, inconsistent and barely maintainable, I'd rather see the above languages used instead.
Java for the server-side of big business applications (i.e. Java is the new COBOL)
C++ when Java is too slow or memory hungry, or for client-side business apps (e.g. GUIs, office software, the recording backend for your particle accelerator)
This list, in this order of preference, has stood me in good stead for years and leads to decisions that are almost always right.
I never recommend TCL or expect, believing them obsoleted by python/ruby. LISP is only a good recommendation for emacs weenies, who live in their own wonderful world and never ask others anyway.
Sorry, no, PHP doesn't qualify as a useful language in my book. I see it as an API the size of a planet driven by a syntax akin to a small, sick dog. Vade retro.
If the XFree86 project truly stalls (and judging by the way other major projects have fractured) then there'll be any number of groups choosing to fork it to develop with their own ideas. Unless they agree on an API or similar framework, this will make it hard for driver vendors like NVidia to target XFree86's derivatives as a platform.
What I predict then is multiple XFree86 fork projects springing up (a la 4.4BSD's fragmentation) and a decline in the quality and quantity of video support for Linux and the BSDs.
What I would *like* to see instead is some cooperation coming out of this. Or possibly a major vendor sponsoring, if they can keep their paws off the direction, an obvious target fork for hardware vendors to work with.
What I'm afraid of is that I will have to go buy an AcceleratedX license.
You don't understand? Time to understand; why are people are chomping at the bit to know?
Simply this: If there is any specific code in Linux that infringes on copyright in a way that attracts liability for users or coders, then it'll be recoded and replaced within days, possibly hours, of public disclosure.
Of course, if SCO don't or can't make a specific claim pointing to specific lines of code, then the rest of us can comfortably brush aside their claims. Certainly they can't demand license fees for something they don't identify; that would be simple extortion.
- J
Re:I think my form of encryption is better
on
RSA-576 Factored
·
· Score: 1
You'd have to be pretty far away and have bad eyesight, because that description is wrong. You've described what is called a "stream cipher", that is, an algorithm that uses a PRNG to generate a keystream. The most popular stream cipher is RC4.
Block ciphers do *not* directly combine a random number stream with the plaintext; they encrypt the plaintext with the key via a defined algorithm. Examples of block ciphers are DES and AES.
Now, it's true that the output of a block cipher can be constantly re-encrypted, thus generating a series of pseudo-random numbers suitable for XORing a plaintext stream; however, that's just a fancy PRNG for a stream cipher! You'd be wise not to equate the two.
As ever, Bruce Schneier's Applied Cryptography is the recommended tome to understand the difference in detail, without gloss.
"ip" is a well-structured command, although the interactions between iproute2 and ifconfig-based interface aliases confuse people (my usual advice is: one or the other).
"tc" is a complex elephant in considerable need of exposure to someone who both a) cares about qdisc and b) understands OS usability. ip & tc are hardly comparable. The "shapecfg" command is more intuitive, but communicates with a completely separate and underdeveloped kernel subsystem.
iptables then has another syntax to learn, just to drive home the point that these subsystems are not well integrated. You can't do everything iptables/Netfilter can in ip+tc; please don't claim this. Functionally, it's almost orthogonal. Fortunately, there are patches available that permit Netfilter firewalls to hook into iproute2/tc and vice versa.
It's not really a happy situation, and designing complex network behaviour for Linux is still an exercise in trial, error, patch integration, and hours of googling.
I couldn't give a damn about end users. Debian is the perfect industrial distribution for serviceprovider people who run loads of servers e.g. me (>250 debian servers internationally).
The moment it starts getting all touchy-feely with some bullshit graphical install and bootloader a la RedHat is the moment I fork it.
The rest of you can follow the market and find the Linux you want. There's plenty of end-user-friendly linux distros. Please stop trying to corrupt the only Linux that really appeals to ISP people. Or we'll have to fork it. Or go back to FreeBSD.
There's almost no way the firmware would be compatible - for one thing, the 10D has that extra dial that marks out the more professionally-oriented bodies in the EOS range.
The 300V is a really handy EOS body, being so lightweight, and the 300D will hopefully retain that convenience factor.
Professionals will smirk at the idiot modes, but this really brings DSLR work into the hands of even more capable amateur photographers.
Perhaps you would care to make some more sweeping assumptions about my computing environment.
We don't run NFS; it's too old, creaking and trusting. We have 20 sites over five continents, and we have laptops. There are many other packages routinely installed and maintained. Special cases make my job, and my team's job, much harder.
Slashdot Mirror
FreeBSD's "portupgrade" system is able to find, build, install, and resolve conflicts in both source and binary distributions of FreeBSD ports/packages even with a moving target of a source tree, with full potential for overrides and magic.
I use it constantly for system maintainence; it fits the Source-based BSD philosophy beautifully, the way APT fits Debian's Binary-package-based orientation.
The only thing that keeps it from being in the base install is that it requires Ruby.
- J
Actually, the legal doctrine of estoppel permits you to rely on a verifiable, unrepudiated statement.
Or more accurately, permits you to claim to the judge that you relied upon it.
For example, one of IBM's counterclaims against SCO is based on the "promissary estoppel" of their prior commitment to the GPL distribution of Linux.
The file formats developed cover both compressed and uncompressed transmission of scent: Nosepeg and .WIF
This argument rests on the assumption that the entire objective is to advance science by providing new practical avenues to justify fundamental research (especially in the field of material science).
If, however, you also want to inspire another generation, and move people's hearts toward space exploration, then every politico knows that the Big Event is where it's at. It's not just the press who aren't interested in football-sized probes. Generally, people aren't cold utilitarians.
- J
Er, for your sake, I hope you sold it short.
Also, given the high level of short interest in SCOX, that you have enough cash to cover a margin call during the short squeeze that's certain to occur.
(my layman's understanding of the situation: the short squeeze occurs when people start to cash in their short positions, jacking the price *up* for a very short term because, by definition, you have to buy the stock to close the short position.
If you can't cover the margin call during the squeeze, you may be forced to buy above your selling price, thus *losing* you money. The stock generally plunges shortly afterwards)
You could just install FreeBSD and then the Debian port. You can then chroot into a Debian jail. Looks like Debian, smells like Debian, but the kernel is FreeBSD. Would that do? :)
I've built Linux kernels inside Debian jails on FreeBSD and they're binary identical (as I would have expected, but it was nice to see it work).
- J
axxackall wrote:
You can make that statement of CVSUp and it will still be true. CVSUp simply has extra support for CVS repositories to make the deltas smaller. For non-CVS data repositories, CVSUp uses rsync/append/copy algorithms as appropriate.
In practice, my experience with CVSUp is that it makes an excellent tool for regularly synchronising fixed repositories specific to an application, and rsync more ideal for sync'ing ad-hoc data.
In particular, I have (at work) a multilevel CVSUp hierarchy distributing large amounts of data internationally and it's been flawless in operation.
- J
I guess they were doing df -k rather than df -ki ...
- J
Astoundingly this "mystery" can be solved by reading his biography :
A statement that is confirmed here.
Perhaps his credentials aren't so "totally bogus" as you claim.
- J
Forgot to paste in; of course, also RFC 1034 (section 3.3), published in 1987.
The patent itself is effectively fraud. Most of the document is occupied with long-winded noise designed to disguise the claim in a torrent of drivel by describing, in excruciatiating, irrelevent and confusingly-numbered detail, a webmail and fax system. The claim itself is only tangentially related to what is written.
Stealing the ideas in a decades-old technical standard? This is yet another embarrassing failure by the USPTO. - J
At least one specific recommendation by a governing body for using hostmaster.example.com. as a DNS label to represent "hostmaster@example.com" can be found here, published well before this patent was filed.
This can also be seen in RFC 1912 (section 2.2), published in 1996.
These muppets have patented something published in one of the very standards they should be familiar with.
- J
Did you read the amendment, the Additional Protocol? It's here.
Notes for discussion as to whether or not this actually "bans ideas":
I argue that incitement to hatred, violence and discrimination is not truth. It is true that those concepts and acts, and their corresponding acts of incitement exist, but they have no intrinsic truth of themselves.
The language "advocates, promotes or incites" is very important. Can I put this more clearly? An example of what is outlawed by this measure might be the statement "Go out and kill Americans, and I will give you some money". This is not an idea; it is an instruction, an act of conspiracy.
Now, under Dutch law, incitement to hatred is already a criminal offence, and denying the Holocaust in certain ways has been interpreted judicially as falling under that legislation. (Holocaust denial is almost invariably an incitement to aggressive neo-Nazi groups).
So perhaps I will revise my statement and put it in context. There is nothing you can't say, but if you harm others with your statements - through incitement to violence, or discrimination - then you may be liable.
- Joshua.
I don't, but that's not because I or my peers are conformist. Having offered conformism as a likely inference and dismissed coincidence as unlikely, Graham leaves out a third possibility: that my peer group is by habit and nature nonconformist and will happily accept and discuss any stated opinion.
The fourth possibility is that Graham means people of my age and cultural background (i.e. Greco-Roman/Anglo-Saxon derived Caucasian), rather than those folk I actually regard as a peer group. I profoundly resent the immediate derivation Graham makes - that "everything you believe is something you're supposed to believe". There are no grounds for reaching this conclusion from the position of lack of fear of wide-reaching discussion and candidness.
This article is a fine piece of fluff, with the low-flying non sequiturs carefully balanced by the empty speculation. Here's another example:
And yet, I wonder. The Dutch seem to live their lives up to their necks in rules and regulations. There's so much you can't do there; is there really nothing you can't say?
Perhaps Mr Graham should actually do some research before he wonders out loud. I lived in the Netherlands for two years, and the answer is yes. There is nothing you can't say. Next question. There's plenty you can't do because astoundingly even the Dutch would prefer not to sponsor murder, child molestation, or deviation from proper procedure.
Woolly thinking and a few historical quotations do not a strong argument make.
- J
It's also a mind-boggling claim that an open architecture was a mistake in the Internet's design. By levelling the field of experimentation, the result has surely being a skyrocketing success.
You can certainly throw together an experimental IP network in your garage with cheap third-hand gear from ebay, swapmeets etc (e.g. old PCs running a free OS, old cisco routers).
Now try simulating a circuit-switched telco network. Not so easy.
- J
When the Junior Unix Sysadmin comes to me, as they do, and asks "what language should I write this tool in?", here is my decision sequence:
- shell (with sed/awk/grep) for process management/job control and line-by-line text processing.
- C for servers, time-sensitive applications, interfaces to syscalls.
- Python or Ruby for complex system tools that benefit from an object model.
- Perl for text mangling. I know; Perl can do anything, and often it's the fastest to write. But as the corollary has it: in Perl, there are too many ways to do it. I usually say that "Using Perl for any of the above is cheating," but what I actually mean is that since most of the perl I've seen produced by anyone below "Guru" status is sloppy, undisciplined, inconsistent and barely maintainable, I'd rather see the above languages used instead.
- Java for the server-side of big business applications (i.e. Java is the new COBOL)
- C++ when Java is too slow or memory hungry, or for client-side business apps (e.g. GUIs, office software, the recording backend for your particle accelerator)
This list, in this order of preference, has stood me in good stead for years and leads to decisions that are almost always right.I never recommend TCL or expect, believing them obsoleted by python/ruby. LISP is only a good recommendation for emacs weenies, who live in their own wonderful world and never ask others anyway.
Sorry, no, PHP doesn't qualify as a useful language in my book. I see it as an API the size of a planet driven by a syntax akin to a small, sick dog. Vade retro.
- J
If the XFree86 project truly stalls (and judging by the way other major projects have fractured) then there'll be any number of groups choosing to fork it to develop with their own ideas. Unless they agree on an API or similar framework, this will make it hard for driver vendors like NVidia to target XFree86's derivatives as a platform.
What I predict then is multiple XFree86 fork projects springing up (a la 4.4BSD's fragmentation) and a decline in the quality and quantity of video support for Linux and the BSDs.
What I would *like* to see instead is some cooperation coming out of this. Or possibly a major vendor sponsoring, if they can keep their paws off the direction, an obvious target fork for hardware vendors to work with.
What I'm afraid of is that I will have to go buy an AcceleratedX license.
- J
They need to update their physics textbook. Modern forces at work include Bureaucracy, Incompetence and Government.
I'll bet any one of those three could breach this fortress ...
You don't understand? Time to understand; why are people are chomping at the bit to know? Simply this: If there is any specific code in Linux that infringes on copyright in a way that attracts liability for users or coders, then it'll be recoded and replaced within days, possibly hours, of public disclosure. Of course, if SCO don't or can't make a specific claim pointing to specific lines of code, then the rest of us can comfortably brush aside their claims. Certainly they can't demand license fees for something they don't identify; that would be simple extortion. - J
You'd have to be pretty far away and have bad eyesight, because that description is wrong. You've described what is called a "stream cipher", that is, an algorithm that uses a PRNG to generate a keystream. The most popular stream cipher is RC4.
Block ciphers do *not* directly combine a random number stream with the plaintext; they encrypt the plaintext with the key via a defined algorithm. Examples of block ciphers are DES and AES.
Now, it's true that the output of a block cipher can be constantly re-encrypted, thus generating a series of pseudo-random numbers suitable for XORing a plaintext stream; however, that's just a fancy PRNG for a stream cipher! You'd be wise not to equate the two.
As ever, Bruce Schneier's Applied Cryptography is the recommended tome to understand the difference in detail, without gloss.
- K
"ip" is a well-structured command, although the interactions between iproute2 and ifconfig-based interface aliases confuse people (my usual advice is: one or the other).
"tc" is a complex elephant in considerable need of exposure to someone who both a) cares about qdisc and b) understands OS usability. ip & tc are hardly comparable. The "shapecfg" command is more intuitive, but communicates with a completely separate and underdeveloped kernel subsystem.
iptables then has another syntax to learn, just to drive home the point that these subsystems are not well integrated. You can't do everything iptables/Netfilter can in ip+tc; please don't claim this. Functionally, it's almost orthogonal. Fortunately, there are patches available that permit Netfilter firewalls to hook into iproute2/tc and vice versa.
It's not really a happy situation, and designing complex network behaviour for Linux is still an exercise in trial, error, patch integration, and hours of googling.
At my office, which manages over 250 debian servers internationally, we call the debian sources by different names.
Stale, Flaky and Broken.
According to their official policy, natch.
I couldn't give a damn about end users. Debian is the perfect industrial distribution for serviceprovider people who run loads of servers e.g. me (>250 debian servers internationally).
The moment it starts getting all touchy-feely with some bullshit graphical install and bootloader a la RedHat is the moment I fork it.
The rest of you can follow the market and find the Linux you want. There's plenty of end-user-friendly linux distros. Please stop trying to corrupt the only Linux that really appeals to ISP people. Or we'll have to fork it. Or go back to FreeBSD.
- J
Looks to me more like a 300V with a digital back.
There's almost no way the firmware would be compatible - for one thing, the 10D has that extra dial that marks out the more professionally-oriented bodies in the EOS range.
The 300V is a really handy EOS body, being so lightweight, and the 300D will hopefully retain that convenience factor.
Professionals will smirk at the idiot modes, but this really brings DSLR work into the hands of even more capable amateur photographers.
Perhaps you would care to make some more sweeping assumptions about my computing environment.
We don't run NFS; it's too old, creaking and trusting. We have 20 sites over five continents, and we have laptops. There are many other packages routinely installed and maintained. Special cases make my job, and my team's job, much harder.
*bzzt*. The keyword was "packaging system".
You obviously don't maintain 250 systems. I do.