The Debian packages are really strange for XBMC. First off the Linux instructions are aimed primarily at Ubuntu. Then the other problem is that there is some kind of a fork between the "official packages" for Ubuntu and the Debian packages provided on debian-multimedia.org, the latter not being up to date (only rc2 is available).
I also note that the Ubuntu packages have an Epoch while the Debian packages do not, which makes it hard to switch between the two.
Short of adding a Ubuntu PPA to my sources.list, I am not sure how I can get this thing installed on Debian, which is a bit annoying.
I wish those great products would actually go the extra mile and work with distributions for their products to be packaged, especially since they seem to be familiar with Debian pacakging...
your fucking comment didn't have a fucking link thank you very much. and i am/sorry/ i didn't read *all* your comments in this thread. now please screw off, prick.
One thing that is not mentionned here is that the 4G specs actually mandate IPv6 and deprecate IPv4 support - something that should really push IPv6 adoption forward, especially with providers that offer both cell phone and traditionnal internet connectivity...
Good thing too. Getting those suckers in would have been difficult otherwise. With IPs running out in Europe this year, we are really starting to feel the pressure now...
First, read the PSNA if you haven't already, it features good ideas on documentation and especially process and how to deal with "layer 8" (management, users, whatever is the "real world" for you).
Next step is the wiki. You seem to already have that, good. People here have suggested SemanticWiki, but I'll point you towards Ikiwiki as it has the advantage of (a) being git based so completely decentralised (have a copy of your files on your laptop during a downtime!) and (b) written in perl so you can probably extend it.
Make sure people know where your wiki is and *use* it, so it doesn't become this rotten piece of outdated documentation out there. You have only started to understand how this is going to be a pain: documenting is hard long-term work. there's a (bad) reason why people don't do it effectively: it takes time and dedication.
Next you can consider using dedicated tools for certain things like inventory or issue tracking. We have used Request Tracker with good success. It's a very solid product that does a lot, also in Perl, coincidentally enough. It also has the Asset Tracker plugin to follow inventory, but i haven't personnally used that, although I had good feedback from peers that used it successfully in an heterogeneous environment. An alternative is OCS inventory, which I haven't used either.
So, just bite the bullet: you're going in the right direction. Just consider the right tool for the right job is your next step, i guess.
I happened to have scanned my modest book library here (~500 items) with GCstar, which works pretty well. It can download covers and details from Amazon and so on, based on the ISBN (although the latest version in Debian fails to do that properly for some reason). Before deciding on GCstar, I had evaluated multiple solutions, including Koha and custom-based solutions, none of which being simple enough for my uses, which made me settle on GCstar... The full details of the evaluation are in the Koumbit wiki.
Since then I have started looking into e-book readers, and family have pointed me to Calibre, a e-book management software. Now it's not necessarily very good with real libraries, but since I am likely to get such a device in the near future (and therefore accumulate digital books), this looks like a very good choice, especially since it seems to have a more complete interface (especially for batch entering ISBN numbers) and a more robust engine to talk with Amazon and friends. It also seems to be better maintained and have a stronger community.
I am not sure that is so helpful in your case, but I thought I could chime in since, well, I have a small library and most of the work is automated.:) Just need to punch in the ISBN number and choose who to lease the book to (something I will do in a custom field in Calibre). A "standard" barcode reader (that behaves like a keyboard, basically) and judicious use of keyboard shortcuts should do the trick if you are really concerned about speed.
It is indeed strange to see Bell throttle people when they have ridiculous bandwidth caps and extra fees in the first place... One has to wonder if this wasn't planned all along: throttle down the connexions because they were not technically capable to force usage-based billing to their customers. Now that they have figured out that bit, they can get in the lucrative business of reselling bandwidth. And they resell that bandwidth at high price.
Doing the math:
10$/mbps/mth - common datacenter bandwidth, in montreal, over a 100mbps pipe, can vary between 5$ to 40$ according to provider
324GB - 1 mbps constant usage over one month (punch this in the excellent "qalculate": 30 * 24 * 60 * 60 second * 1megabit/second to gigabyte)
125GB - highest bandwidth cap you can get from Bell
0.39mbps - equivalent of that in mbps, constant use, over the month (125 gigabyte / (30 * 24 * 60 * 60 second) to megabit/s = 0,38580247(megabit/s))
59.95$/mth - price of that package
24.95$/mth - price for the 2GB (!) package
35$/mth - effective price for a 0.39mbps commitment
90$/mth - effective price for a 1mbps commitment with bell, over a 20mbps pipe
So. This means that bandwidth is sold by bell 90$/mbps whereas they are paying probably something closer to 10$ or even 5$/mbps, probably even less considering the monopoly and sheer volume. We could also observe how those prices usually also involve a 100mbps pipe, whereas Bell offers you a 20mbps connexion. Of course, those are datacenter prices which do not cover the connectivity costs, but still, one could assume those are covered by the 25$/mth base price.
And i'm not even talking about how competitors of Bell *can't* even offer 25$/mth packages because *they're* base price is over 30$/mth... No wonder they fought so hard to try to charge their competitors based on usage too: it is the only edge they have left. (This is still in the cards, by the way.)
I am also ignoring the fact that Bell is also a *content* provider which puts them in a conflict of interest: throttling people and charging them extra for downloading stuff helps them sell their digital TV offerings and other revenues
... and while i won't go as far as signing this comment (i admire the dedication folks, but really...), i try to use it as much as possible. I have done PGP trainings for the masses (see this and this, in french) and I'm doing my best to strenghten the web of trust.
I am also very curious to see where the STEED project leads us, it looks like a nice way to popularize PGP.
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.
First issue: This is great if you have an external system to log to - if not, you're boned. This new logging system seems to cover both cases.
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.
Second issue: One of the big reasons for doing this is to be able to detect when the log has been altered to cover a crackers tracks. Obviously, a deleted log file is easily detected and a big indicator that your system has been compromised, so I'm not seeing your point here.
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.
Third issue: As has been stated above, you can log to both the Journal and good old text based log files. That way you can still use your existing tools on the text file while still being notified of log file alteration. I agree that a common format for log entries would be nice but may not be possible since not every application logs the same kind of data. Note also that this proposal allows for arbitrary key/value pairs so some standard conventions will probably come about after its been used for a while.
Somebody else answered to this, but yeah: if you're going to file to logfiles anyways, why bother with the journal?
Fourth issue: Not sure I understand what you are talking about here... Obviously, backward compatibility will have to be taken into account by the devs. You should be able to read the files on other machines if you backed up your encryption keys, etc. (you do backup that stuff right?). By reading the articles, it sounds like the devs have thought about these issues and/or they have already been raised by others. They seem to be fairly easy to deal with.
Backward compatibility doesn't seem to have been taken into account by the devs. It's in the FAQ:
Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures? At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)
I'm not necessarily on board with this proposed system either, but your issues seem like they've already been covered by the proposed design.
I can mostly agree with you. There is one thing you might be missing.
[...]
I think what you are missing is this replacement is intended to prevent "undetected" tampering with the logs. Currently, a cracker can delete the log entries that would identify his or her activities on the machine, thereby going unnoticed. Deleting the log files or destroying the tools, as you suggested, would certainly be a detectable sign that the machine was compromised.
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:
Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
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.
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...
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.
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 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!
Slashdot Mirror
i have stopped using telnet when i discovered swaks. It just rocks.
The Debian packages are really strange for XBMC. First off the Linux instructions are aimed primarily at Ubuntu. Then the other problem is that there is some kind of a fork between the "official packages" for Ubuntu and the Debian packages provided on debian-multimedia.org, the latter not being up to date (only rc2 is available).
I also note that the Ubuntu packages have an Epoch while the Debian packages do not, which makes it hard to switch between the two.
Short of adding a Ubuntu PPA to my sources.list, I am not sure how I can get this thing installed on Debian, which is a bit annoying.
I wish those great products would actually go the extra mile and work with distributions for their products to be packaged, especially since they seem to be familiar with Debian pacakging...
your fucking comment didn't have a fucking link thank you very much. and i am /sorry/ i didn't read *all* your comments in this thread. now please screw off, prick.
thanks for the source anyways. :P
Justice Minister Vic Toews [...] is a divorced philanderer and has fathered children outside his own marriage.
Source?
Some sources:
* https://en.wikipedia.org/wiki/IPv6_deployment
* http://www.circleid.com/posts/20090609_verizon_mandates_ipv6_support_for_next_gen_cell_phones/
* https://www22.verizon.com/opendev/Forum/LTE_Document_Archives.aspx
* https://en.wikipedia.org/wiki/IPv4_address_exhaustion#Regional_exhaustion
One thing that is not mentionned here is that the 4G specs actually mandate IPv6 and deprecate IPv4 support - something that should really push IPv6 adoption forward, especially with providers that offer both cell phone and traditionnal internet connectivity...
Good thing too. Getting those suckers in would have been difficult otherwise. With IPs running out in Europe this year, we are really starting to feel the pressure now...
First, read the PSNA if you haven't already, it features good ideas on documentation and especially process and how to deal with "layer 8" (management, users, whatever is the "real world" for you).
Next step is the wiki. You seem to already have that, good. People here have suggested SemanticWiki, but I'll point you towards Ikiwiki as it has the advantage of (a) being git based so completely decentralised (have a copy of your files on your laptop during a downtime!) and (b) written in perl so you can probably extend it.
Make sure people know where your wiki is and *use* it, so it doesn't become this rotten piece of outdated documentation out there. You have only started to understand how this is going to be a pain: documenting is hard long-term work. there's a (bad) reason why people don't do it effectively: it takes time and dedication.
Next you can consider using dedicated tools for certain things like inventory or issue tracking. We have used Request Tracker with good success. It's a very solid product that does a lot, also in Perl, coincidentally enough. It also has the Asset Tracker plugin to follow inventory, but i haven't personnally used that, although I had good feedback from peers that used it successfully in an heterogeneous environment. An alternative is OCS inventory, which I haven't used either.
So, just bite the bullet: you're going in the right direction. Just consider the right tool for the right job is your next step, i guess.
I happened to have scanned my modest book library here (~500 items) with GCstar, which works pretty well. It can download covers and details from Amazon and so on, based on the ISBN (although the latest version in Debian fails to do that properly for some reason). Before deciding on GCstar, I had evaluated multiple solutions, including Koha and custom-based solutions, none of which being simple enough for my uses, which made me settle on GCstar... The full details of the evaluation are in the Koumbit wiki.
Since then I have started looking into e-book readers, and family have pointed me to Calibre, a e-book management software. Now it's not necessarily very good with real libraries, but since I am likely to get such a device in the near future (and therefore accumulate digital books), this looks like a very good choice, especially since it seems to have a more complete interface (especially for batch entering ISBN numbers) and a more robust engine to talk with Amazon and friends. It also seems to be better maintained and have a stronger community.
I am not sure that is so helpful in your case, but I thought I could chime in since, well, I have a small library and most of the work is automated. :) Just need to punch in the ISBN number and choose who to lease the book to (something I will do in a custom field in Calibre). A "standard" barcode reader (that behaves like a keyboard, basically) and judicious use of keyboard shortcuts should do the trick if you are really concerned about speed.
It is indeed strange to see Bell throttle people when they have ridiculous bandwidth caps and extra fees in the first place... One has to wonder if this wasn't planned all along: throttle down the connexions because they were not technically capable to force usage-based billing to their customers. Now that they have figured out that bit, they can get in the lucrative business of reselling bandwidth. And they resell that bandwidth at high price.
Doing the math:
So. This means that bandwidth is sold by bell 90$/mbps whereas they are paying probably something closer to 10$ or even 5$/mbps, probably even less considering the monopoly and sheer volume. We could also observe how those prices usually also involve a 100mbps pipe, whereas Bell offers you a 20mbps connexion. Of course, those are datacenter prices which do not cover the connectivity costs, but still, one could assume those are covered by the 25$/mth base price.
And i'm not even talking about how competitors of Bell *can't* even offer 25$/mth packages because *they're* base price is over 30$/mth... No wonder they fought so hard to try to charge their competitors based on usage too: it is the only edge they have left. (This is still in the cards, by the way.)
I am also ignoring the fact that Bell is also a *content* provider which puts them in a conflict of interest: throttling people and charging them extra for downloading stuff helps them sell their digital TV offerings and other revenues
... and while i won't go as far as signing this comment (i admire the dedication folks, but really...), i try to use it as much as possible. I have done PGP trainings for the masses (see this and this, in french) and I'm doing my best to strenghten the web of trust.
I am also very curious to see where the STEED project leads us, it looks like a nice way to popularize PGP.
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.
First issue: This is great if you have an external system to log to - if not, you're boned. This new logging system seems to cover both cases.
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.
Second issue: One of the big reasons for doing this is to be able to detect when the log has been altered to cover a crackers tracks. Obviously, a deleted log file is easily detected and a big indicator that your system has been compromised, so I'm not seeing your point here.
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.
Third issue: As has been stated above, you can log to both the Journal and good old text based log files. That way you can still use your existing tools on the text file while still being notified of log file alteration. I agree that a common format for log entries would be nice but may not be possible since not every application logs the same kind of data. Note also that this proposal allows for arbitrary key/value pairs so some standard conventions will probably come about after its been used for a while.
Somebody else answered to this, but yeah: if you're going to file to logfiles anyways, why bother with the journal?
Fourth issue: Not sure I understand what you are talking about here... Obviously, backward compatibility will have to be taken into account by the devs. You should be able to read the files on other machines if you backed up your encryption keys, etc. (you do backup that stuff right?). By reading the articles, it sounds like the devs have thought about these issues and/or they have already been raised by others. They seem to be fairly easy to deal with.
Backward compatibility doesn't seem to have been taken into account by the devs. It's in the FAQ:
Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)
I'm not necessarily on board with this proposed system either, but your issues seem like they've already been covered by the proposed design.
I disagree with this analysis. :)
I can mostly agree with you. There is one thing you might be missing.
[...]
I think what you are missing is this replacement is intended to prevent "undetected" tampering with the logs. Currently, a cracker can delete the log entries that would identify his or her activities on the machine, thereby going unnoticed. Deleting the log files or destroying the tools, as you suggested, would certainly be a detectable sign that the machine was compromised.
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:
Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
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'.
/var/log
rm -rf
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!