True, ReiserFS exists now. But you completely avoided his question.
ReiserFS has a lot of cool features but without applications taking advantage of said cool features, it is as relevant to most users as the non-existent WinFS.
On the contrary, I pay my fees and taxes and whatnot for national and cable TV no matter whether I watch any of those expensive shows or not. So what's the difference where I watch it, TV or downloaded? Fox gets paid for 24 by the TV stations who show it and they get their money from their users, subscribers, taxes, ads, whatever.
I downloaded this season of Lost and 24 off Usenet, and I'm in the same position: I pay for cable and could have watched these live, but due to timing (I recently moved and missed a bunch of episodes so I had to catch up) getting them from Usenet was easier. I asked myself the same question you did, and the most obvious answer (that came to mind immediately, so it may need to be refined) is that watching shows this way have all the ads cut from them. Overall, if more and more people watch content this way (with ads edited out), I think it's pretty likely that advertisers will notice their compaigns becoming less and less effective. As a result, the amount of money made by the stations for advertising will decrease, and this will trickle down the chain to the actual shows themselves.
I have no idea what the numbers would be. But I think this is a realisitic result. Obviously as it is right now, grabbing series off Usenet or bt or wherever is still fringe enough that it probably doesn't affect their bottom line much, but I do believe there is a threshold (in terms of number of viewers who watch content this way) where it would affect the value of advertising.
So the networks will have to deal with the loss, or find a better model to deal with these new trends. I don't leech episodes from Usenet because I'm cheap or broke, but because this is the model that's most convenient for me. I even pay for it (via my Usenet account), and if the networks (and movie studios too) had a model that worked for me (that didn't require me to use Windows and deal with shitty DRM'd content) then they could get my $10/mo instead of my news provider.
This is my problem with yum - it is god awful slow.
I can't disagree. Quite frequently I would type 'yum install foo', wait 10-15 seconds while yum appeared to be doing nothing, open a new term and ftp to the repository and grab the files myself. I could even manually resolve 2 or 3 dependencies in less time than it would take yum to finish. It was infuriating, and the only time I would ever use yum is if it was something that involved dozens of dependencies or more.
Fortunately the situation is improving. yum on fc5 actually doesn't suck. It's not awesome, but it doesn't suck; it still needs to be faster, but much of the time it's faster than me, which makes it a useful tool. I think we can expect to see even more improvement in the future.
I've never understood the attraction of Vim, maybe someone could explain. It seems like a throwback to keyboard command line editors with it's modal editing.
A lot of it, I'll admit, is habit. My brain is tightly wired to vim's keyboard shortcuts (some of which are quite obscure) to the point where thinking about some action in vim is roughly equivalent to that action actually happening. I've also become accustomed to vim's slightly more esoteric features. Would other editors do the same job and be less obscure about it? Quite probably. But the truth is that vim works for me, I've already overcome the steep learning curve, and there's really very little incentive to use something else.
Now, if I were to start fresh, would I still choose vim? I think the answer is a resounding "probably." Here are some reasons why:
vi is ubiquitous, and vim is pretty common itself. vim is usually available, and when it's not (on older unixes say) I can still apply what I know to vi to get my job done. Obviously for those who aren't sysadmin types who only use one unix, this isn't much of an argument.
vim is text-mode; I can shell in and use it remotely just the same as using it locally. Obviously there is a trade-off here, and any text-based editor (joe, nano, etc.) have the same advantage. But it's why I don't use gedit.
vim is agile and powerful. I never have to reach for a mouse (or rather, I can't reach for the mouse) so you get quite proficient at common operations. vim has features like syntax highlighting and folding that I like for coding. Any modern programmer-oriented editor does this too, but vim does it all while being fast.
vi[m]'s ubiquity I think is its strongest argument. Other editors exist to satisfy the other requirements, and some of them might even do it in less obscure ways. But if you're the type who needs to bounce around on different systems running different unixes, vi is always just there. And once you become proficient enough, you're really not strongly inclined to use anything else.
vim 8 will do email
on
Vim 7 Released
·
· Score: 3, Informative
A spellchecker? Now, to be fair, I'll probably find that useful. Still I can't help but feel vim is one step closer to proving jwz's law.
RIM is a Canadian company, and the US patents involved do not apply to RIM's business in Canada and presumably other non-US countries. The same situation will happen to other companies, whether they are in China or India, if they wish to do business in the US. So I do agree that the whole patent nonsense is impeding innovation, but if a company wants to tap into the US market, they're going to have to deal with this problem until it gets fixed (which, I suspect, I won't live to see).
But following the instructions I gave you, the password is readable only by someone with root access. By storing them in a PHP file, users other than root can read it.
I suppose technically what you said earlier is true: a password stored in a file only root can read is more secure than a password stored in a file any user can read. But this statement doesn't preclude the possibility of ensuring the php file that contained the password is readable only by apache. Any admin who allows other users to read such a file is incompetent anyway, and I think the reason others here are casting you perplexed looks is that properly configuring access control on a file holding a password is just obvious stuff, whether that's a php file readable by the apache user, or some other plaintext file readable only by root.
I can certainly buy an argument that it's good practice to store passwords in a file specifically designated for the task, if you ever need to store a password in the clear. I do this myself, mainly for convenience, so that I'm not changing a bunch of scripts every time I change the password. And if you store the files in some clearly labeled place (like/etc/secrets, which is what I use), you could easily argue that you're more likely to be careful about access control and less prone to mistakes, which is a security advantage.
But fundamentally it's all the same, and the approach you suggest is not "far more secure" as long as the files have the appropriate ACLs.
Use Apache directives to create an environmental variable with the password stored in it. This way, you can store the password in a file only root can read. That's far more secure than storing the password in a PHP file any user can read.
How is this fundamentally different from hardcoding the password in a php file? In either case, the password is readable.
Push email. I ran an agent on my Outlook at work and email appeared on my Blackberry, subject to the filtering rules I put in place. This is better than IMAP and POP3, I literally only saw emails I care about on the device. I'd much rather design my filters in an Outlook-like interface than on a small device.
I noticed that this release of opera supports the opacity style. It's viciously slow, but hopefully they'll improve things for the final release. Still no support for column-width though.
And ID doesn't even qualify as that. ID is innately untestable and therefore not falsifiable. If we can't even test the validity of a statement, can we call it a hypothesis?
if every thumb drive was 1cm square, you would lose within a week
As long as they could still be attached to a keyring, it could be as small as physically possible, and I would lose it about as often as I lose my keys. (Which has never happened yet; knock on wood.)
Oh, God, not you too! You started off sounding so bright. Over and over and over again, it must be explained that what's easy to use depends on what you were used to before.
Are you suggesting here that software can't benefit from usability testing? I understand your point (that what's usable is relative to user's background), but that point doesn't support the implication that usability testing is unnecessary.
Of course, I also think the grandparent's rant about vim was nonsense (common FUD: find one of Linux's most obscure and complicated programs [which is not really discoverable anyway, at least on my distro] and use that as an example for why Linux is difficult). Perhaps this is really what you were talking about, but in that case you should have quoted a different part of his post.
I have observed that, by and large, the best hackers have excellent language skills. Those who have mediocre programming abilities are equally mediocre in prose.
I'm just not getting a good feeling about this guy's cluefulness. In general, the language is vague and wishywashy, and feels like he's read a whole lot on the topic but doesn't grok it at a level that he should before writing about it.
For example, he doesn't seem to know what an IV is, and suggests there's something fundamentally wrong with them:
Every time a packet is sent this shared key is paired with another key called an Initialization Vector, together these form the encryption in the packet. The Initialization Vector is included in the packet, which makes it security vulnerability. That is not the only problem with Initialization Vectors; the other problem is there is a limited amount of them, only 16,777,216.
If I didn't know better, I'd draw the conclusion, "Wow, stay away from these things called initialization vectors. Oh no! My DriveCryptLeetMagicFantastico uses this thing called AES-CBC that requires initialization vectors! It must be broken!"
He also says that CRC32 is a good measure to increase protection, except that it's just poorly implemented in WEP.
There are many better write-ups on WEP security available, like this one.
Except for the size, they look the same to me. Same kerning, same antialiasing, same ligatures (observe the "ft" in "Lifts"). The fact that Firefox is rendering fonts smaller may or may not be a bug in Firefox. But have you tried increasing the font size in Firefox until they're the same, and then comparing?
You may choose to use Konqueror for a list of valid reasons, but in terms of fonts, I think your case is far from rested.
I don't understand why Slashdot (a place I like to think of being pretty well grounded in approaches to technology reviews) has gotten caught up in this blog nonsense. Blogs are not news.
Just because it's content posted in a blog doesn't mean it's not news, or not reliable. Should I avoid reading what Bruce Schneier has to say just because he posts it in a blog? Or maybe I should wait until next month for him to release his Cryptogram where he basically reposts the same stuff?
Like any other source, you have to evaluate it based on its merits. But dismissing it out of hand because it's a blog is silly.
Slashdot Mirror
I wrote No Squint. I will add a feature in the next release that lets you override the default zoom increments.
True, ReiserFS exists now. But you completely avoided his question.
ReiserFS has a lot of cool features but without applications taking advantage of said cool features, it is as relevant to most users as the non-existent WinFS.
Agreed. Go vote for https://bugzilla.mozilla.org/show_bug.cgi?id=98971 (note
I have no idea what the numbers would be. But I think this is a realisitic result. Obviously as it is right now, grabbing series off Usenet or bt or wherever is still fringe enough that it probably doesn't affect their bottom line much, but I do believe there is a threshold (in terms of number of viewers who watch content this way) where it would affect the value of advertising.
So the networks will have to deal with the loss, or find a better model to deal with these new trends. I don't leech episodes from Usenet because I'm cheap or broke, but because this is the model that's most convenient for me. I even pay for it (via my Usenet account), and if the networks (and movie studios too) had a model that worked for me (that didn't require me to use Windows and deal with shitty DRM'd content) then they could get my $10/mo instead of my news provider.
It's been two minutes since I clicked this and I'm still laughing.
Fortunately the situation is improving. yum on fc5 actually doesn't suck. It's not awesome, but it doesn't suck; it still needs to be faster, but much of the time it's faster than me, which makes it a useful tool. I think we can expect to see even more improvement in the future.
Now, if I were to start fresh, would I still choose vim? I think the answer is a resounding "probably." Here are some reasons why:
vi[m]'s ubiquity I think is its strongest argument. Other editors exist to satisfy the other requirements, and some of them might even do it in less obscure ways. But if you're the type who needs to bounce around on different systems running different unixes, vi is always just there. And once you become proficient enough, you're really not strongly inclined to use anything else.
A spellchecker? Now, to be fair, I'll probably find that useful. Still I can't help but feel vim is one step closer to proving jwz's law.
RIM is a Canadian company, and the US patents involved do not apply to RIM's business in Canada and presumably other non-US countries. The same situation will happen to other companies, whether they are in China or India, if they wish to do business in the US. So I do agree that the whole patent nonsense is impeding innovation, but if a company wants to tap into the US market, they're going to have to deal with this problem until it gets fixed (which, I suspect, I won't live to see).
Unfortunately, without subpixel precision the Ken Burns effect looks too lame.
I can certainly buy an argument that it's good practice to store passwords in a file specifically designated for the task, if you ever need to store a password in the clear. I do this myself, mainly for convenience, so that I'm not changing a bunch of scripts every time I change the password. And if you store the files in some clearly labeled place (like /etc/secrets, which is what I use), you could easily argue that you're more likely to be careful about access control and less prone to mistakes, which is a security advantage.
But fundamentally it's all the same, and the approach you suggest is not "far more secure" as long as the files have the appropriate ACLs.
I noticed that this release of opera supports the opacity style. It's viciously slow, but hopefully they'll improve things for the final release. Still no support for column-width though.
Actually N is 3. It's not known if N > 3 will provide greater anonymity. See the Tor FAQ for more details.
Jason.
And ID doesn't even qualify as that. ID is innately untestable and therefore not falsifiable. If we can't even test the validity of a statement, can we call it a hypothesis?
Jason.
As long as they could still be attached to a keyring, it could be as small as physically possible, and I would lose it about as often as I lose my keys. (Which has never happened yet; knock on wood.)
Jason.
Of course, I also think the grandparent's rant about vim was nonsense (common FUD: find one of Linux's most obscure and complicated programs [which is not really discoverable anyway, at least on my distro] and use that as an example for why Linux is difficult). Perhaps this is really what you were talking about, but in that case you should have quoted a different part of his post.
Jason.
I have observed that, by and large, the best hackers have excellent language skills. Those who have mediocre programming abilities are equally mediocre in prose.
For example, he doesn't seem to know what an IV is, and suggests there's something fundamentally wrong with them:
If I didn't know better, I'd draw the conclusion, "Wow, stay away from these things called initialization vectors. Oh no! My DriveCryptLeetMagicFantastico uses this thing called AES-CBC that requires initialization vectors! It must be broken!"
He also says that CRC32 is a good measure to increase protection, except that it's just poorly implemented in WEP.
There are many better write-ups on WEP security available, like this one.
You may choose to use Konqueror for a list of valid reasons, but in terms of fonts, I think your case is far from rested.
It must have been gruelling to have to wait for the next Firefox story before you could use that one.
Just because it's content posted in a blog doesn't mean it's not news, or not reliable. Should I avoid reading what Bruce Schneier has to say just because he posts it in a blog? Or maybe I should wait until next month for him to release his Cryptogram where he basically reposts the same stuff?
Like any other source, you have to evaluate it based on its merits. But dismissing it out of hand because it's a blog is silly.
Jason.
Jason.