Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
SMF is all XML, if you want to read the configuration or make your own, you can.
That's a huge problem, though: XML is a markup language, not a configuration language. Although it can be used to represent any data, it is not ideal for representing many kinds of data (in much the same sense that being Turing-complete is hardly sufficient to be a decent programming language).
YAML, s-expressions, traditional Unix line-oriented config filesâ"heck, even Windows-style
Some people, when they have a data representation problem, think, 'I know, I'll use XML'; now they have two problems.
Refusing to acknowledge what science teaches us about disease is illogical and yet you are holding yourself up as an arbiter of logic.
Who said anything about what science has discovered about disease? All science can say is, 'if you smoke, your risk of lung cancer is increased'; it cannot determine whether that risk is worthwhile.
I'd argue that the risk is worthwhile when it comes to cigars and pipes, and not when it comes to smoking a pack a day of cigarettes, jsut as the risk of eating grilled meat is well worth it.
The DNS system by nature has a single root, the trust chain doesn't necessarily have that.
The SPKI guys back in the 90s figured this stuff out really, really well. Ideally, one would have: a DNS trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of owns example.net; an IP trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of the owner of 192.0.2.7, and possibly certifications from other organisations (Better Business Bureau perhaps) that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of a decent dude; users' browsers might demand the first two and show more confidence for further certifications.
SPKI's contributions included a k-of-n standard and, more importantly, transitive authorisations. So once I am granted authorisations from
You can see how this might work with internet governance: each organisation would be responsible for the namespace it was assigned, and be easily able to segment that namespace however it wished. Anyone at any level could cross-certify; damage to the trust chains could be contained.
SPKI is, in every way save uptake, superior to XPKI.
Link to Original Source
- Bootable backup
- This isn't a big deal to me because I RAID everything; that's the appropriate use of RAID (it's not a backup; it provides stability). The appropriate use of backups is to preserve data, not provide stability. However, I understand that not everyone can afford to spend 3x the disk (1 for the original, 1 for the mirror, 1 for the disk), even taking advantage of cheap offsite backup services like Amazon S3, so I think your idea makes sense for those folks. Easy enough to add as an additional feature.
- Sub-file increments
- Agreed. Venti/fossil did these aeons ago and we can now. There's really no good reason not to, especially with offsite backups (saves transfer bandwidth and update costs). Merkle hash trees aren't rocket science!
- This is not a simple problem in any environment--this isn't just limited to Linux. A naive implementation might preserve a snapshot of a file when it's opened, and then delete it when it's closed. For databases and other systems, this could conceivably consume far too much space. A more intelligent implementation might improve on this, albeit at the cost of complexity and concomitant bugs. I don't know much about btrfs's solution. I don't think this is necessary for the home user, and the systems user is knowledgeable enough to know how to take snapshot or quiesce, or whatever, when needed.
- Ease of use
- That's probably easy enough to do with a special partition type (so it can be recognised as a backup on other systems; this also permits use of an efficient backup-oriented format rather than forcing backups to live atop ext* or whatever). On first insert, record the unique ID of the drive; if it's to be used for backup reformat. I would be concerned about foolish users just clicking through any number of dialogues and accidentally destroying their pre-existing data on the drive though--this happens a lot.
So...why don't you write it? I'm sure the world would love it! Compared to a lot of other software, it's really not all that complex. Just remember to encrypt the backups...
I have glumly come to the conclusion that if I want something equivalent to or better than MacOS's Time Machine on Linux for doing time-based incremental backups, I'm going to have to write it myself, and it's going to have to rely on LVM's snapshotting mechanism to do a consistent backup until BTRFS is ready.
You might take a look at using rsync for incremental backups. I've been doing this and it works great.
Essentially, getting caught leaving cookies otherwise should be evidence of the attempt, and bill them.
So you want to enter your username and password every time you reload a page, every time you post a comment &c.? Or you're cool with URLs which look like 'http://www.example.com/page?sessid=37a1-fb6c-9372-11de' instead or 'http://foo:email@example.com/page' instead of 'http://www.example.com/page'?
Do you even know what cookies are, what they do or why they were added in the first place?
(defclass a () ((b
:accessor b :initform 1 :type (integer 0 100))))
Although it's up to your implementation whether or not to enforce the type declaration.
Of course, what would be darkly ironic would be a screw-with-crackers script with a security vulnerability...
You are sounding rather limited in your own grasp of world history - many enlightened countries of the modern world prohibit weapons, and none of of them have totalitarian governments.
That's both a paetitio principi and a non sequitur. It begs the question because it assumes that weapons bans are enlightened (and hence not totalitarian; it doesn't follow because by banning weapons those countries are by definition totalitarian.
Having a gun in a fight works if the fight is nearly fair. Two men with pistols each have a decent chance of winning a gunfight. We aren't talking about that here. We're talking about a civilian against soldiers, plural. Guns don't help there. Other weapons do.
Which is why the Constitution says nothing whatsoever about 'guns' and merely says 'arms,' which includes those other weapons. Yes, I think if someone wants to buy a wire-guided missile or a cruise missile or a howitzer or a fighter jet then he has a constitutional right to do so. And yeah, most folks wouldn't--but they could, which is what liberty is all about.