You know, this looks very interesting actually. I wouldn't be so bold as to say that it's "taking on Google", but it's a great idea. For example, right now it looks like yacy.net is down (maybe because of us, btw) - but you can just install it on your own Linux-based machine and you can still search the network, heck there's even an apt repository.

From there you get your own search engine, which you can even use to only search your LAN or private network. You can not only use that to search the distributed database, but also crawl your own sites, to improve the results for your community.

Think about it: no more profiling of your searches, no more dependency on a central authority for results. More importantly, no more single point of failure for the collective knowledge of mankind. Seems to me like a good goal.

That is a pretty good start, I would say. Of course we shouldn't expect the results to be better or even close to Google's, but if we all jump in and help this project, this could become something decent.

Or we could just sit back in our usual armchair specialist posture and say it's all crap. This is slashdot after all...

Maybe there's a sweet spot between "no testing at all" and "replacing everything every three months"? In my experience, there is a lot of work to do in most places to make sure that proper testing is done, or at least that emergency procedures are known and people are well trained in them. Very often documentation is lacking and the onsite support staff have no clue where that circuit breaker is. That is the most common scenario in my experience, not overzealous maintenance.

No, it doesn't: it does not protect you if you do not log to a another server or at least backup the hashes somewhere else. You still need a secondary server.

Well, I was making a rather broad stroke on that one. As I explained earlier, just like with git rebase you can certainly tamper with the logs without being detected, if you are root, so this doesn't cover that case unless (again) you use a secondary server.

Somebody else answered to this, but yeah: if you're going to file to logfiles anyways, why bother with the journal?

Backward compatibility doesn't seem to have been taken into account by the devs. It's in the FAQ:

I disagree with this analysis. :)

My point is: even with git if someone has access to the repository it *can* be tampered with. It's harder and may take longer than with a plain text file, but it's completely possible. With git, there's even an easy way to do it (git rebase) and I suspect that cracking toolkit will adapt and also make that easier. Note that I assume here that you save the first hash of the tree to a secure location, as documented:

If only the topmost hash is saved to a backup location, then I just need to reroll all the logs from that first topmost hash and tampering goes undetected. The only argument for this technique is that you could keep more than just the first hash (say N hashes), which we could argue goes back to logging to a different machine, for a sufficiently high N.

There is a project called Monkeysphere which have been working on doing this and much more with PGP for a while. They support SSL certificates in the browser (with some difficulty) and SSH host keys authentication, and generally aim to bridge the PGP web of trust with other tools to decentralize the work of certification authorities.

How does Convergence compare with Monkeysphere? Why didn't you collaborate with the Monkeysphere project instead of starting your own?

Now, without getting into how much i dislike Pulseaudio (maybe because i'm an old UNIX fart, thank you very much), I think there are really serious issues with "The Journal", which I can summarize as such:

1. the problem it's trying to fix is already fixed
2. the problem isn't fixed by the solution
2. it makes everything more opaque
3. it makes the problem worse

The first issue is that it is trying to fix a problem that is already easily solved with existing tools: just send your darn logs to an external machine already. Syslog has supported networked logging forever.

Second, if you log on a machine and that machine gets compromised, I don't see how having checksums and a chained log will keep anyone from just running trashing the whole 'journal'.

rm -rf /var/log

What am i missing here?

Third, this implements yet another obscure and opaque system that keeps the users away from how their system works, making everything available only through a special tool (the journal), which depends on another special tool (systemd), both of which are already controversial. I like grepping my logs. I understand http://logcheck.org and similar tools are not working very well, but that's because there isn't a common format for logging, which makes parsing hard and application dependent. From what I understand, this is not something The Journal is trying to address either. To take an example from their document:

MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
[... 14 lines of more stuff snipped]

(Nevermind for a second the fact that to carry the same amount of information, syslog only needs one line (not 14), which makes things actually readable by humans.)

The actual important bit here is "User harald logged in". But the thing we want to know is: is that a good thing or a bad thing? If it was "User harald login failed", would it be flagged as such? It's not in the current objectives, it seems, to improve the system in that direction. I would rather see a common agreement on syntax and keywords to use, and respect for the syslog levels (e.g. EMERG, ALERT, ..., INFO, DEBUG), than reinventing the wheel like this.

Fourth, what happens when our happy cracker destroys those tools? This is a big problem for what they are actually trying to solve, especially since they do not intend to make the format standard, according to the design document (published on you-know-who, unfortunately). So you could end up in a situation where you can't parse those logs because the machine that generated them is gone, and you would need to track down exactly which version of the software generated it. Good luck with that.

I'll pass. Again.

The article doesn't say to which protocols the agencies are switching to. This could be an issue.

As weak the current (clear-text) system sounds like, there is no expectation of privacy, and officers know that. In Montreal at least, when they need to communicate privately, they exchange cell phone numbers and talk over the phone, which is considered more secure (something could be said about that too).

With an encrypted system, the officers will then expect the whole network to be secure and will therefore say a *lot* more on the airwaves. As soon as a radio is stolen or the protocol cracked, the whole thing will fall apart and then much more information will be revealed.

The more secure the system, the higher the risk.

I like the idea that the current system is transparent, and allow even ham radio operators to communicate with emergency teams in case they need to. This just makes sense. Encrypting everything seems like a bad move, and probably a business scam too.

What's different here is that Ford is now shipping software to their customers, as opposed to having their customers go back to their favorite garage and have the mechanic plug the car into a magic computer, that often even he has only a faint clue of how it works. This is a significant paradigm shift. It means that Ford will be able to manage more frequent software releases, and maybe start thinking about changing whole features within the lifetime of the car, outside of regular "oh you need to have an inspection after 100 000km" kind of things. So that's cool.

Now the bad part is that your "computer-car" stays proprietary software, and there will probably still be no way in hell that you will be able to modify that software yourself, unless you do some reverse engineering. But it necessarily opens up interesting avenues like running Rockbox on your radio receiver, or flashing some controllers with free software for some of us that are into that kind of crazy thing. I say "necessarily" because the car owners do not have the proprietary interfaces to interoperate with the car, which are a significant barrier of entry for us wannabe car hackers.

In order for Ford to deliver that software to joe users, it means it has to lower this barrier of entry, and that can only be a good thing for everyone.

Considering how disconnected politicians and lawmakers are from technology issues in general, i think it's a fairly good idea to post the ad in a newspaper. Seems to me this bill should be stopped with all means available...

we're all out.

i wish this would have worked out and that we would won. but it seems "democracy" is only useful when we need to bomb the hell out of a nation we don't like.

http://www.stopacta.info/about

maybe there's still time to reverse that idiocy. suggestions?

So wait - why doesn't this use the existing PGP web of trust and software?

And how does it mitigate the MITM/Phishing attacks that plagued OpenID?

I'm skeptical, but encouraged to see some efforts here...

The wikipedia page details which ATVs are connected and where. Then I had to figure out what the heck Poisk and Pirs were and that was in the Poisk page.

I have just finished such a annotated graphic, I hope you enjoy it. This was actually a lot of fun to do, and I learned a lot.

Wikipedia has a lot of information on the different modules that make up the space station in the ISS page.

I am always fascinated by Linux version numbers. I can't quite figure out what they mean, and I suspect I'm not the only one. Reading that "2.6.40 is more distinct from 2.6.0 than 2.6.0 was from 2.0.0" doesn't make any sense to me. For my projects, I have always intuitively followed the Semantic Versionning principles: x.y.z, where X is a major version, Y is a minor version and Z is a patch release. You increment X when you change the API. You change Y when you add a feature. You change Z when you make a small bugfix. Simple and clear. Linux, on the other hand, seems to follow more the whims of Linus than any logical process, which seems to be a common pattern in this project, and which is not always for the worst though...

Seems to me saying "no one talked about google" is really overlooking a key issue in current geopolitics, namely the 6.4b$ arms sales that the US is preparing with Taiwan. Now, that's the kind of things that can get China annoyed... who cares about google!