"Found only on FreeBSD..."
Also found on NetBSD, OpenBSD and DragonFlyBSD.
74 karma · joined July 18, 2013
Also found on NetBSD, OpenBSD and DragonFlyBSD.
FYI
rdiff is the reference implementation or first example of a utility written with librsync, which is the library that Dropbox used to build their "business".
Usage: rdiff [OPTIONS] signature [BASIS [SIGNATURE]] [OPTIONS] delta SIGNATURE [NEWFILE [DELTA]] [OPTIONS] patch BASIS [DELTA [NEWFILE]]
Options: -v, --verbose Trace internal processing -V, --version Show program version -?, --help Show this help message -s, --statistics Show performance statistics Delta-encoding options: -b, --block-size=BYTES Signature block size -S, --sum-size=BYTES Set signature strength --paranoia Verify all rolling checksums IO options: -I, --input-size=BYTES Input buffer size -O, --output-size=BYTES Output buffer size -z, --gzip[=LEVEL] gzip-compress deltas -i, --bzip2[=LEVEL] bzip2-compress deltas
It does one thing only: deduplication.
All the other stuff needed for remote, incremental backups, e.g., moving files back and forth over a network, can be done with other open source tools. I think I have a pretty good command of moving files around with open source software... I do not need a third party to help me via an obfuscated blob of Python and who knows what else.
I like having control over my backups versus trusting it all to some closed-source, third party, "all-in-one" application.
In my mind having control and transparency will always be more powerful than handing over my data deduplication and backup to a third party, such as "Dropbox".
But I imagine there are few others who would agree. Forgive me for not loving Dropbox. Maybe some day I will see the light.
You can write one-off (or reuseable) filters in minutes.
lex/flex should be in every UNIX distribution that has a C compiler, but maybe that's changing.
awk '!($0 in a);a[$0]; print}'
I rarely if ever use uniq to remove duplicates. Sorting is expensive.
I was referring to the case where the email is redirecting to (or through) an unintended recipient.
Before my comment is further misinterpreted, let me make clear:
I am not saying "Do not use SSL/TLS." By all means use it; regardless of the bugs, the complexity and the lack of an acceptable authentication mechanism.
But encrypting before transport is even more important, IMO. And so that is a more interesting statistic.
The two are not mutually exclusive.
Not to mention one could use SSH for encryption "in transit". It has better authentication than SSL/TLS, but that's only my opinion.
Who cares? I'm more interested in knowing the percentage encrypted _before_ transport.
"During transport" requires authentication; otherwise all bets are off.
"Before transport" at least minimizes the damage if the email is sent to the wrong recipient.
I have yet to see an authentication mechanism that looks "trustworthy" (decentralized and simple), other than a pre-sharing some identifier face-to-face.
Same goes for the use of "read-only" mounts and "RAM disks" as opposed to dependence on other, less reliable media.
I hope your comment continues to be upvoted; usually I see downvotes at any mention of static linking. Why, I can never be sure. If static binaries make some power user's life easier why should anyone else care? With reasonably-sized, well-written programs (or the use of a system like Go's), compilation can be quite fast. And easy enough for anyone to do if and when libraries change.
But when I try to compile knot it demands a lot more resources than compiling djbdns (tinydns), or nsd. A bit too much IMO.
There is some amusing djb-phobia in this thread. Reminds me of djb-bashing from years gone by. Always good for a laugh. Time has shown the wiser.
Despite many early detractors (for reasons unknown), his software is still going strong without major flaws while the popular alternatives (who are often grubbing for consulting bucks) have suffered embarassment after embarassment because of poor design and sloppy coding. Unlike the usual bloated crapware that needs to be fixed/upgraded umpteen times (how is this ever a sign of quality?), his stuff is rarely if ever updated. Because it does not need to be. It just works. And keeps on working. In recent years it seems to me his work (crypto-focused) is now gaining more widepsread popularity. Never thought I'd see it in something like OpenSSH.
I use djb programs daily, from qmail to daemontools to ucspi to sntpclock to cdb. All very reliable. I wish there were more authors who could do what djb does. a@kx is another one I admire, but k is not open source. I think my favorite aspect of djb software is how cleanly it compiles, no matter what system I've got. His more recent packages do not even use make!
Anyway, if the guys behind knot can get it to compile as cleanly and easily as tinydns (or even nsd), I'll give it another shot. But methinks I should not need GB's of RAM or some hugh swap space to compile a simple authoritative dns server. Simplicity is paramount. To me, anyways.
I may have to get one of these Turris routers. Nice work.
Anyway, I didn't think about what happens if you create one file called "-e" and then do
echo *
echo rm *
echo chown -R nobody:nobody *.php
echo chmod 000 *
echo tar cvvf archive.tar *
echo tar cf archive.tar *
echo rsync -t *.c foo:src
Later in the article we learn that it also assumes GNU utilities. That is a second problem (IMO), and arguably also one more serious than the behaviour of wildcards. GNU userland and unneeded complexity (e.g. more features than any user will ever use) are practically synonymous.
Then there is the peculiar assumption that someone can place arbitrary files beginning with - or -- on this system. That itself is a far more serious problem than the behaviour of wildcards; I would say with that capability it is more or less "game over". In BSD you have, at the very least, mtree. How does the Linux user know she isn't executing some substituted executable?
Moreover, if caution was important to the hypothetical user in the examples, I think they would be in the form
/path/to/program *"You've got the causality reversed. We're not bizarro world because we sue so much; we sue so much because we're bizarro world. To put it another way, it's not surprising that a small, high-trust, high-equality, high-consensus society like Denmark has much less need for formal dispute resolution than a large, low-trust, low-equality, low-concensus society like the U.S."
Notice how he shifts from bizarro-land to "bizarro world".
The rest of the world is not in all cases just like bizarro-land, or much worse. But when you are in bizarro-land, that's how the media often portrays it. And perhaps believing this makes it easier to tolerate bizarro-land and being stuck in it. Those with such a world view have my greatest sympathies.
"... low trust, low equality, low consensus society."
Sounds wonderful.
What was that old Star Trek episode with the "energy force" shaped like a ball spinning near the ceiling causing everyone on the Enterprise to fight each other?
Yes, that is how things will look if you live in a sane country like Denmark.
But as the top post in this thread acknowledges, in bizarro-land people structure their lives (and "careers") according to the television. And TV says being a lawyer can only lead to good things. Moreover, most bizarro-land parents will agree with the television set.
There was a Congressional study in bizarro-land a number of years back. The title went something like: "Bizarro-land. Can we sue our way to prosperity?"
There will always be lots of litigation in bizarro-land. Because that is how they do business. When business succeeds, they sue. When business fails, they sue. Litigation is itself big business.
If you read HN, then you know about the USPTO. The bizarro-land government issues rights to sue called patents and trademarks. Needless to say, these rights to sue are extremely popular there; probably more popular in bizarro-land than anywhere else in the world. Why? In bizarro-land, one can never have too many potential lawsuits ready to file.
Can we sue our way to prosperity? "Yes, we can."
There can never be too many lawyers in bizarro-land.
I hope in DK that the taxes people pay go back to the people in some form.
Because in bizarro-land the taxes people pay go to businesses that would otherwise fail. Banks get "bailed out". Universities go after the student loan programs (as mentioned in the article). Pharmaceutical companies go after the medical benefits programs. And so on. Consumers can no longer afford the overpriced products and services of these failing businesses, so the businesses go after the government coffers: get the government to pay for them!
Denmark is one of the better countries you could live in anywhere in the world. Count your blessings.
I think this goes beyond email.
Similar to the way consumer applications gratuitously became big and slow as processor speed increased and magnetic drive space increased, today we see gratuitous use of increased network bandwidth.
As such if there is even a momentary problem with the remote network, then there will likely be a problem with your application. Many of today's applications have no "offline" mode. Network availability and performance is assumed. Just as back in the 90's it became assumed that the user would have a capable PC. A "slow" PC would not run the latest software.
Many of the applications I write for my own use require very little computing power... I develop on a modestly powered machine and so my programs can run fast from old hardware if need be (i.e., can't afford the latest gear). My approach to "apps" is to periodically download bulk data from the network to keep the application updated, and this usually is scheduled for off-peak times when costs and congestion are lower. Fast network speeds and inexpensive local storage are much appreciated when performing these updates. Not to mention the ease of obtaining an internet globally reachable IP address through today's "cloud hosting" providers.
But I will never understand today's "app" and "web API" trends. Developers of these "apps" utilize the costs of storage and bandwidth a different way. Storage is mainly remote (on someone else's machines, not yours), and hence controlled by some third party, not the user. And most of these applications I see are designed to make constant piecemeal downloads, minute by minute, hour after hour, day after day (even if the same information has been requested before) when they could just as well download all the data they will ever need once, and periodically update it during off-peak periods. As such, if the network is congested or down at runtime, the user must suffer it out. Of course, by making a call to the remote network every time the user takes some action, third parties are able to track everything a user does. That, and the whole app/api approach to development has value to some people perhaps, but surely it is not users. For example, when I watch YouTube videos, I have an application that downloads them first, storing them on RAM disk or inexpensive local media storage and then serving them over a local network. I can then play them using whatever device suits me (or store them on any other device if I wish). I never see any ads. I never use Javascript or Flash. And I never have playback issues (because among other things I have control over my local network). This approach seems like common sense but I feel like I am probably one of the only people out there who does this... and it is not difficult at all to do.
The author's command of the English language easily trumps any deficiencies in multiplication. His little quips crack me up. "All that and a can of paint."
"Rump" is just a cool name in my opinion. I liked rump(3) before I even knew what it did. Naming and coming up with clever acronyms that are not annoying is difficult. Props to the author for that alone.
Whereas something like "Docker" makes me cringe. No matter how good it is. Some of these names people come up with are just terrible.
Anyway, we know that rump can be used for mounting filesystems (e.g., ones containg applications) that reside on USB sticks or other removable media. By using rump_ffs, there is no kernel panic on errors associated with the mounted filesystem. For that one use alone, nevermind its otherwise enormous potential, I'd say rump is worth the rumpification of the NetBSD source tree. It is not easy to crash the netbsd kernel, but filesystem errors are one way to do it, in my experience.
I think the author should have at least one article about rump that uses a certain song title from Exile on Main Street.
Glad to see others in this thread reflecting a similar sentiment.
I still prefer a wired connection, where possible. Not because I like wires, but because it is more reliable and the protocol is easier to understand.
I have the well-traveled internet in my HOSTS file.
No DNS lookups, recursive or not, is always faster than 1 or more.
When this sort of discussion comes up, I always ponder the number of IP addresses that constitutes the "traveled internet" for any given user. I believe it is a relatively small number. The truth is, unless you are running internet-wide scans or something, you will only visit a small fraction of the total IP address space in your lifetime. And in my case I believe I can store all those IP addresses, in additon to a large number of addresses I might visit, on my own personal storage. I'd imagine I visit more addresses than the average user, so the number becomes even smaller in that case.
Another thing I'll mention is an article on the Cisco website from a number of years back where someone claimed that the optimum number of users for a DNS cache is only, if I recall correctly, about 10.
I'd say it's healthy to check your assumptions. You might find that large shared DNS caches, like the ones offered by ISP's or "open resolvers", are not always faster than the alternatives for all queries. Believe me, I do a lot of experimenting with caches in additon to using authoritative queries, local authoritative servers and /etc/hosts. Despite what theory and logic suggest, caches are not always faster across all lookups.
If there were hard and fast rules about how to configure DNS to minimize the number lookups and make DNS as efficient as possible, and everyone followed them, then maybe things would be different. As a simple example, try counting the number of queries required to resolve a host when Akamai is used. I don't care what the large, shared cache of the "well-traveled internet" has, because I already have all the fully resolved Akamai IP numbers where the content resides in my local storage. And if one location is slow I can manually choose another.
Then why are they using a DNS cache run by a third party (who they do not know) on the open internet, and shared with other users they do not know? The entire focus on DNS insecurity that brought about the renewed interest in "DNSSEC" can be traced to a "cache poisoning" scare back in 2008. The rational response to that aspect of DNS insecurity is to move away from shared DNS caches on the open internet, aka "open resolvers".
If "integrity" were the goal, then I would think downloading a trusted copy of the root.zone and running your own root and DNS cache on localhost would be a better approach. Additionally, if you have many double-digit GB's to spare, you could add in copies of the com, net, or org zones. Allowing users to download trusted copies of these is required by the ICANN rules. Alas, Country Code TLD's are not governed by these rules. Imagine if the telephone company would not allow you to have a copy of the telephone book and said you could only call the operator when you needed to look up a telephone number. That's what it's like when public registries withhold zone files. But I digress...
Setting up and maintaining a local DNS cache is a lot easier than setting up DNSSEC.
Really, the only queries you need to be sending out over the open internet are ones to the third party authoritative nameservers that are responsible for the information you are after. That means non-recursive queries only. I have been doing this for years and it works beautifully. In some cases, it can be faster to make only a series of non-recursive queries to authoritative nameservers than to make a recursive one to a cache. I also store the DNS information for hosts I know I might revisit in HOSTS and zone files. This minimizes my need to use DNS. And looking up information in HOSTS and zone files (in cdb format) is always faster than third party DNS.
Once you have achieved this sort of localized setup, and you no longer rely on third parties for DNS (e.g. such as OpenDNS, GoogleDNS, DNS.Watch, etc.), then you may come to the conclusion that the more important DNS security issues are 1. how to verify that the authoritative nameservers you query are the right ones (not imposters), and then 2. how to secure the packets you exchange with the authoritative nameservers.
There is a finished solution available for 2, but not for 1.
Unless you think delegating 1 to a third party is a "solution" (e.g., PKI, CA's managed by third parties like Verisign, etc.).
Lastly, even if you do not care much or at all about DNS security, there are gains in reliability and sometimes performance to be had by using a local cache (and ideally as much locally stored DNS information as possible) versus using a third party cache on the open internet. You get the additonal security of not using shared caches (i.e. minimized risk of cache poisoning) "for free."
As a side note, what would happen if we put our own private address space "web apps" on our gateway? Voila, the added "web app" functionality that our devices expect, without the need to use third party servers on the public internet that collect personal info.
In any event, if you do not have a Pi, you could just as well use any old i386 computer and any old DNS server software.
I use a gateway like this not to block ads but to detect and, if necessary, stop mobile apps that phone home (and send out payloads of private data). You would be amazed at what some of these apps want to send over the internet for no good reason.
And, rather than use a HOSTS file as a blacklist, I use it as a whitelist by populating it with all the sites I might visit.
For example, using a localhost recursive DNS server, I pre-fetch all IP addresses for all the sites appearing on HN and put them in /etc/hosts. This makes reading articles posted on HN much, much faster than if using an ISP's DNS cache or some public, open resolvers like OpenDNS or Google.
Again, my compliments to the author for a great use of a small form factor general purpose computer.
What language does she prefer? Does she prefer complexity or simplicity? Is her code verbose or terse? So many questions.
Does any of this matter? If you're into coding, then the answer is "Yes", in my opinion. In fact, when it comes to software, I really do not care about what the coder looks like, what clothes the coder wears, the coder's personality type, etc. In evaluating software, these things are all irrelevant to me. I only care about the coder's code sensibilities and tastes, and the quality of the code.
Anyway, can we see any code samples to back up her statement? I will believe it when I see the evidence.
No matter what he says or does in real life, and even if he wears cheap suits and ugly ties, I will always have an appreciation of one well-known, former CEO as a coder. Because lex is one of my favorite programs.
And I'm sure these "free" programs, with all their vulnerabilities, have resulted in quite a few dollars in "consulting" fees which he and his "not-for-profit" (=pay no taxes) organization (ISC) has billed for "support" over the years.
Of course, there's nothing wrong with getting paid for your work. It's when you produce bug-ridden programs that are intended for widespread public use and then claim they are the "gold standard" that you may face criticism.
And now he's in the "security" industry. It is indeed comical.
But since you mentioned it, it's not unfathomable to think that NSA could help the situation. The search technology they develop, e.g. Binney's work with B+ trees, is funded with tax dollars. Maybe the public should be allowed to use it (not the data, necessarily, but the software). I wonder who would argue search technology is some sort of weapons-grade "munitions" like was claimed about cryptography.
The benefit might be a dramatic reduction in internet crime without the cost of (over) regulating the internet.
I respectfully, but strongly, disagree.
While you or I might be able to find what we are looking for, we cannot extrapolate this to mean that "users" (in the general sense) can do the same. Moreover, I'm not satisfied with the status quo of locating stuff on the internet. It's better than it used to be, but I believe we can do better - much better.
But considering what Wikipedia is, users wanting increased privacy could just download a copy of the encyclopedia and do their searches offline. Wikimedia makes data dumps of their user-generated content (UGC) available to the public. (Don't you wish all mega-websites relying on UGC did that?)
There was a time before the internet when we used volumes of paper bound encyclopedias. These were not written by laypeople and they were not free. Few people owned their own set of volumes of Brittanica's encyclopedia. They used someone else's copy, e.g., a library's.
But imagine if Brittanica offered _free_ copies of their encyclopedia that could somehow fit in your pocket (as is possible now through digitization and Wikipedia).
Would you continue to use a copy belonging to someone else everytime you had to look something up? Why wouldn't you obtain a copy for yourself?
What if... Wikipedia's data dumps were small enough. Wikipedia content was, overall, static enough. Storage was cheap enough. Download speeds were fast enough. And you could get your very own copy of the encyclopedia.
Compared to the speed, reliability and privacy of offline reading, grabbing specific articles piecemeal via HTTPS simply cannot compare.
See OpenMoko's WikiReader as an example implementation. It's on Github.
Imagine further that the "calf-cow" model of the web could be replaced with something more decentralized, e.g. a "content-centric" network instead of a "source-centric" one... such that there would be little room for "selling" traffic.