Which may be why Zimmerman's defense didn't invoke SYG.
IMHO, there was not proof beyond a reasonable double that Zimmerman was on top. It's quite possible he was on the bottom, and was legitimately scared for his life. From what I know from the trial, I don't think I'd have convicted either.
On the other hand, from what I know from the trial, I also wouldn't have convicted TM if TM had managed to kill Zimmerman. It's a crappy situation for everyone.
You're assuming that the drive failures are independent. His point is that they might not be: the common cause may be write cycles.
Let's say that a drive under your write patterns will last 9 months. (Bad wear leveling algo, combined with very re-write heavy data structures?). You put 5 of them in a raid 5 enclosure, all brand new drives. 9 months later, they all fail within minutes of each other. Whoops, lost your data.
If they fail for different reasons, you're more likely to be safe. If they all fail from wearing out the ability to erase cells, you're more likely to be hosed, until you've swapped out enough to randomize the write count./p?
You posted this in reply to an O'Reilly promotion. You know, the one company who's ebook format is "unencrypted PDF". That one. The one company that CAN NOT take your book away. Where the book won't change unless you want it to. Where you can keep it on your own HD for as long as you can and no one will even know.
Excuse me for being a horrible pedant, but I would also get confused if you told me to put a disk into the DVD drive. That drive takes discs... the ones that are visibly circular and have no case.
Ahem. Back to your point, and sorry for making the point of the original article.
I had a small OCZ SSD of some variety in my foo-server (which mounted the NAS for all the important changing data). One day I realized that / had gone ready-only days earlier. Console showed a write failure to the journal (ext3).
Rebooted it, and it worked for ~1 day. Reformatted (managed system, I have no idea if there was data corruption. Didn't seem to be any, but I didn't look for any) and it worked for around 1 week. At that point I gave up and replaced it. It had lasted for just over a year when it failed.
The two Intel SSDs I've bought have not failed yet, nor has another OCZ brand SSD (Vertex3, fwiw).
I wrote an interface to OSS back in... 98? Something like that. It was dead simple to use: configure device, write sound data. Done.
Handling underflow/overflow was also so easy (write ahead as much as the device will take. Use an IOCTL when you need to stop... because the buffer won't run out for several seconds) that it amazes me that buffer sizes apparently have to be configurable in current sound-using applications. Crazy.
Maybe because for my workflow (lots of windows running vim or shells, all open at once, on the same huge screen along with at least one web browser), the new shiny isn't actually moving forward.
This. Like Enry, I've been using linux since pre-1.0. Unlike him, I've lost my desire to constantly upgrade versions.
The "KDE/Gnome are both Windows 95/XP look-alikes" era was probably the top of the usability as far as I can tell. Newer KDE never got back to the same level of usability, and newer gnome makes me turn giant and green. (Look, my monitor is not 1024x768. Stop making UI decisions that only work on tiny-ass monitors.)
And unlike most here, I think that is reasonable. Normal people won't use Linux until the app they want is only available on it... and that won't happen until the developer likes it enough to run it as their default platform. So YES, make it nice for neckbeards first. And once it's (back to being) nice for the neckbeards, THEN go ahead and try and make it nice for your grandmother too... but DO NOT break it for the neckbeards.
And then you declare the basic desktop DONE for 3 years or so, and work on apps. Maintain the desktop in terms of bug fixes, and internal reworks and anything else you need to do, but religiously keep interfaces static for 3-10 years. And instead of going all 2nd system on the interface, work on other things. Maybe those are easier app-building tools? Maybe those are actually just killer apps. Maybe those are better tools for configuring the system, or for managing large numbers of desktops. Maybe that's "work on something completely different that doesn't affect the desktop". Whatever. Maybe that's "work on something completely different, like servers". I don't really care, as long as you stop breaking perfectly working desktops.
Re:Apple's lack of support for Retina Displays
on
Linux 3.5 Released
·
· Score: 4, Interesting
Kinda off subject here, but...
Your standard app was not written for silly-high DPR. You could show this on linux too: take your desktop, and crank the DPI to 300 or so, so that the X server thinks your screen is only 5" across. Now move far enough away from it that a 12 point font looks reasonable, and then look at how stupid apps look. Icons are microscopic (because they're defined in fixed pixel sizes). Layouts between menubars and borders look stupid (natural spacing was defined in fixed pixel sizes).
So Apple's approach here is to tell the application that the screen is 1440x900. Any primitives that can be scaled ("place the string 'pants' in font 'Helvitica', size 12pt, at X,Y". "Draw this 2kx2k pixmap in this 500px x 500px space") are then rendered to the screen's native resolution. Things that can't be scaled aren't ("draw this 96x96 pixmap here, in this 96x96 space"). Some apps then look horrible, some look great.
I personally would have rather they just let apps look like crap, and told people to fix their darn apps, but I can understand why they didn't.
and then once they've excavated what your MAC address is, telling your router to route traffic to your node is trivial.
Could you further explain this attack vector, cause I've not really understood it so far. The bad guy has your IP address. Exactly what is the additional harm in letting him know your MAC address?
I understand the issue of "probable iphone MAC => iphone specific vulnerabilities", but that doesn't seem to be what you're talking about here. (And really, that's not a significant barrier to the attacker anyway. You did something that let him see your IP address: the odds are quite good that he already could figure out your OS more reliably than using a MAC -> OS mapping)
Since my work laptop isn't allowed to join my "home" workgroup, there is no DNS which will work between by laptop and my machine
Huh? Um, exactly what's the DHCP server on that network there? Does that DHCP server advertise a DNS server? Can you modify the DNS server?
Alternately, can turn of the DHCP server on that wireless router that only does caching recursive DNS, and install a DNS server and DHCP server on your other computer, and run that?
And then, why again do you need to run your own DNS server anyway? Won't the people who give you the/64 take requests to add records? Or use one of the dynamic DNS protocols that allows you to register your IP? And I think there's yet another answer that involves anycast and autoconf...
Or maybe I'm just completely not understanding what you mean by "join my 'home' network".
IPv6 has some pretty good autoconf out of the box. You use RADVD to just announce services, you don't need any software managing IP addresses because the nodes will do that themselves. And when you want to use some service that isn't a pure client-server-http thing, the fact that each computer has a unique IP on that other side of the firewall is helpful. And for the most part, the "OMG, that's hard" retoric is horribly overblown. Get a/64. Configure a route-announce daemon (things your ISP can do for you). IPv6! Free!
Setting up a game, I was trying to debug a connection problem someone had, and sent them to a site that tells you IP addresses. A different friend went there, and discovered he had an IPv6 address. His ISP had provided it for him, and he had literately never known. It wasn't relevant. That's the experience you should expect.
Actually, I just recently did it. (with a Galaxy Nexus, not an iPhone, but that shouldn't be a huge difference).
Now, I'm paying the same amount I would under contract. I was getting a break with T-Mobile though.
Just FYI, depending on exactly when in 2010 it was hacked, Verisign may not have been in the certificate business. Symantec purchased the business in May of 2010, and IIRC the operational transfer happened pretty quickly.
That "just" leaves the DNS system as a possible valid target. You know, the system that's probably more important than SSL.
Verisign runs the top-level domain DNS servers for com, net, edu, cc, name, and a few other smaller ones. If you lookup gmail (ignoring caching), you have to ask Verisign-owned servers where the google DNS servers are, so you can ask those servers what the gmail IP address is. For the security of the internet: it's pretty important.
Until late 2010, Verisign also ran the dominant SSL business. That red circle with the black digitized check at the bottom of your bank's web page? Yeah, that. The SSL business was sold to Symantec, are are trying to slowly rebrand. For the security of the internet, SSL is also kinda important.
The configuration of a system is much more complex than most configuration management tools consider. The tools generally limit themselves to the list of things a "sane" person would change.
The list of things that actually affect the running of your system is much, much larger.
Libraries. Did you hand-jam in a specific openssl version for some application?
Programs. Did you hand-upgrade openssh on one system?
/usr/local. Is it in the path of a shell script used to launch a service? Is everything under it managed?
Permissions. Did someone do "chmod -r" somewhere they should not have?
If you write rules in puppet to handle all of that, your set of rules blows up to be insanely detailed, long, and completely unmanagable.
But the reinstall handles it all. In an automated, scripted fashion that allows you to easily change what you need.
Seriously people. Cobbler & similar install servers. They need to be part of any large scale host management. And since they are already there, are easy to leverage into being a large part of your large scale host management. And then reinstalling the server is the sane solution.
cfengine, puppet, chef et all are in the set of acceptable solutions. And if you have per-host information you care about keeping, superior to blindly reimaging.
But why do you have per-host information? Per-host information (log files, or important data on local storage) is an inherent management pain. The best answer is to keep that to the minimum set of hosts possible, and use coarse tools on the majority. Then you're manually managing 2 hosts, and bulk managing 998. Which is a cubic ton better than manually managing most of 1000 hosts. (remote syslog is your friend.)
(Upgrade? Really? Um, no. Reinstall. Again, you have to be able to reinstall quickly and accurately. And since you can do that, why not do that?)
And then, once you figure out what's wrong, you should reimage the box to fix it. Yes, I'd dead serious. Manually futzing with one box ("configuration drift") is farther up the list of reasons why things break than you would believe.
You have 1000 servers. You need to upgrade them to RHEL 6. Do you put a DVD in each of 1000 DVD drives?
NO!
You use an image server. Kickstart. Cobbler. Figure out how the new image looks like, and then pxeboot 1000 servers. That goes much faster. (to the sysadmin above, reimaging a server should take 25 minutes, most of which is spent surfing slashdot, not an hour).
So now, you've got a server that's misbehaving. One of 1000. Out of pure coincidence, honest, the one server you were manually futzing with last week, but that can't possibly be connected. Fixing that server yourself will cause more "configuration drift", and leave you with one server that's still different than the 999 other servers. And hey, that image server is still on your network. Just reimage the thing.
It's popular because it's the answer that scales. kthxbye.
The user would be none the wiser if the user had never gone to that encrypted site before with that browser and stored the key. It's the SSH trust model, only with a bad rap.
I believe your delusion is thinking that the people pirating your music actually searched for it. Rather, the odds are good that they did broad search, and then downloaded everything. After all, they were already at the relevant web site, they'd already downloaded one thing, the marginal cost (in time at the keyboard) of downloading everything was pretty close to zero. And hey, while they had never heard if it, what's the hard in giving it a try.
So they did. And then never bothered listening to it again.
I don't have any advice for you, other than better advertising. DRM doesn't work, and converting someone who pirated it to a buyer only works for subsequent releases.
But the kids who downloaded it from the Pirate Bay? They aren't your customers, and those are not lost sales. They wouldn't have bought it anyway, so you're not really losing money from them.
Slashdot Mirror
(and given payola pushes this down to "makes money per stream", likely has an argument)
Which may be why Zimmerman's defense didn't invoke SYG.
IMHO, there was not proof beyond a reasonable double that Zimmerman was on top. It's quite possible he was on the bottom, and was legitimately scared for his life. From what I know from the trial, I don't think I'd have convicted either.
On the other hand, from what I know from the trial, I also wouldn't have convicted TM if TM had managed to kill Zimmerman. It's a crappy situation for everyone.
You're assuming that the drive failures are independent. His point is that they might not be: the common cause may be write cycles.
Let's say that a drive under your write patterns will last 9 months. (Bad wear leveling algo, combined with very re-write heavy data structures?). You put 5 of them in a raid 5 enclosure, all brand new drives. 9 months later, they all fail within minutes of each other. Whoops, lost your data.
If they fail for different reasons, you're more likely to be safe. If they all fail from wearing out the ability to erase cells, you're more likely to be hosed, until you've swapped out enough to randomize the write count./p?
That company.
No, helping the country be better, and the citizen be better off is.
Aka: Leading the country.
Getting elected is a MEANS, it is not the end.
Excuse me for being a horrible pedant, but I would also get confused if you told me to put a disk into the DVD drive. That drive takes discs... the ones that are visibly circular and have no case.
Ahem. Back to your point, and sorry for making the point of the original article.
I had a small OCZ SSD of some variety in my foo-server (which mounted the NAS for all the important changing data). One day I realized that / had gone ready-only days earlier. Console showed a write failure to the journal (ext3).
Rebooted it, and it worked for ~1 day. Reformatted (managed system, I have no idea if there was data corruption. Didn't seem to be any, but I didn't look for any) and it worked for around 1 week. At that point I gave up and replaced it. It had lasted for just over a year when it failed.
The two Intel SSDs I've bought have not failed yet, nor has another OCZ brand SSD (Vertex3, fwiw).
I wrote an interface to OSS back in ... 98? Something like that. It was dead simple to use: configure device, write sound data. Done.
Handling underflow/overflow was also so easy (write ahead as much as the device will take. Use an IOCTL when you need to stop... because the buffer won't run out for several seconds) that it amazes me that buffer sizes apparently have to be configurable in current sound-using applications. Crazy.
Maybe because for my workflow (lots of windows running vim or shells, all open at once, on the same huge screen along with at least one web browser), the new shiny isn't actually moving forward.
This. Like Enry, I've been using linux since pre-1.0. Unlike him, I've lost my desire to constantly upgrade versions.
The "KDE/Gnome are both Windows 95/XP look-alikes" era was probably the top of the usability as far as I can tell. Newer KDE never got back to the same level of usability, and newer gnome makes me turn giant and green. (Look, my monitor is not 1024x768. Stop making UI decisions that only work on tiny-ass monitors.)
And unlike most here, I think that is reasonable. Normal people won't use Linux until the app they want is only available on it... and that won't happen until the developer likes it enough to run it as their default platform. So YES, make it nice for neckbeards first. And once it's (back to being) nice for the neckbeards, THEN go ahead and try and make it nice for your grandmother too... but DO NOT break it for the neckbeards.
And then you declare the basic desktop DONE for 3 years or so, and work on apps. Maintain the desktop in terms of bug fixes, and internal reworks and anything else you need to do, but religiously keep interfaces static for 3-10 years. And instead of going all 2nd system on the interface, work on other things. Maybe those are easier app-building tools? Maybe those are actually just killer apps. Maybe those are better tools for configuring the system, or for managing large numbers of desktops. Maybe that's "work on something completely different that doesn't affect the desktop". Whatever. Maybe that's "work on something completely different, like servers". I don't really care, as long as you stop breaking perfectly working desktops.
Your standard app was not written for silly-high DPR. You could show this on linux too: take your desktop, and crank the DPI to 300 or so, so that the X server thinks your screen is only 5" across. Now move far enough away from it that a 12 point font looks reasonable, and then look at how stupid apps look. Icons are microscopic (because they're defined in fixed pixel sizes). Layouts between menubars and borders look stupid (natural spacing was defined in fixed pixel sizes).
So Apple's approach here is to tell the application that the screen is 1440x900. Any primitives that can be scaled ("place the string 'pants' in font 'Helvitica', size 12pt, at X,Y". "Draw this 2kx2k pixmap in this 500px x 500px space") are then rendered to the screen's native resolution. Things that can't be scaled aren't ("draw this 96x96 pixmap here, in this 96x96 space"). Some apps then look horrible, some look great.
I personally would have rather they just let apps look like crap, and told people to fix their darn apps, but I can understand why they didn't.
Lets see YOU sir figure up an IP V6 address map for...lets say a 40 person small business, in your head.
Ok.
That was easy.
Could you further explain this attack vector, cause I've not really understood it so far. The bad guy has your IP address. Exactly what is the additional harm in letting him know your MAC address?
I understand the issue of "probable iphone MAC => iphone specific vulnerabilities", but that doesn't seem to be what you're talking about here. (And really, that's not a significant barrier to the attacker anyway. You did something that let him see your IP address: the odds are quite good that he already could figure out your OS more reliably than using a MAC -> OS mapping)
Huh? Um, exactly what's the DHCP server on that network there? Does that DHCP server advertise a DNS server? Can you modify the DNS server?
Alternately, can turn of the DHCP server on that wireless router that only does caching recursive DNS, and install a DNS server and DHCP server on your other computer, and run that?
And then, why again do you need to run your own DNS server anyway? Won't the people who give you the /64 take requests to add records? Or use one of the dynamic DNS protocols that allows you to register your IP? And I think there's yet another answer that involves anycast and autoconf...
Or maybe I'm just completely not understanding what you mean by "join my 'home' network".
IPv6 has some pretty good autoconf out of the box. You use RADVD to just announce services, you don't need any software managing IP addresses because the nodes will do that themselves. And when you want to use some service that isn't a pure client-server-http thing, the fact that each computer has a unique IP on that other side of the firewall is helpful. And for the most part, the "OMG, that's hard" retoric is horribly overblown. Get a /64. Configure a route-announce daemon (things your ISP can do for you). IPv6! Free!
Setting up a game, I was trying to debug a connection problem someone had, and sent them to a site that tells you IP addresses. A different friend went there, and discovered he had an IPv6 address. His ISP had provided it for him, and he had literately never known. It wasn't relevant. That's the experience you should expect.
Actually, I just recently did it. (with a Galaxy Nexus, not an iPhone, but that shouldn't be a huge difference). Now, I'm paying the same amount I would under contract. I was getting a break with T-Mobile though.
That "just" leaves the DNS system as a possible valid target. You know, the system that's probably more important than SSL.
(Yes, I know that my reply is missing the joke. I thought it was important to post anyway)
Until late 2010, Verisign also ran the dominant SSL business. That red circle with the black digitized check at the bottom of your bank's web page? Yeah, that. The SSL business was sold to Symantec, are are trying to slowly rebrand. For the security of the internet, SSL is also kinda important.
So google's doing it wrong? So is Yahoo? They shouldn't have so many computers? How about Amazon? Supercomputers are all doing it wrong?
It's called "running a successful service at internet scale". And it's a really good gig if you can get it
A second specific comment
The configuration of a system is much more complex than most configuration management tools consider. The tools generally limit themselves to the list of things a "sane" person would change.
The list of things that actually affect the running of your system is much, much larger.
If you write rules in puppet to handle all of that, your set of rules blows up to be insanely detailed, long, and completely unmanagable.
But the reinstall handles it all. In an automated, scripted fashion that allows you to easily change what you need.
Seriously people. Cobbler & similar install servers. They need to be part of any large scale host management. And since they are already there, are easy to leverage into being a large part of your large scale host management. And then reinstalling the server is the sane solution.
cfengine, puppet, chef et all are in the set of acceptable solutions. And if you have per-host information you care about keeping, superior to blindly reimaging.
But why do you have per-host information? Per-host information (log files, or important data on local storage) is an inherent management pain. The best answer is to keep that to the minimum set of hosts possible, and use coarse tools on the majority. Then you're manually managing 2 hosts, and bulk managing 998. Which is a cubic ton better than manually managing most of 1000 hosts. (remote syslog is your friend.)
(Upgrade? Really? Um, no. Reinstall. Again, you have to be able to reinstall quickly and accurately. And since you can do that, why not do that?)
You should.
And then, once you figure out what's wrong, you should reimage the box to fix it. Yes, I'd dead serious. Manually futzing with one box ("configuration drift") is farther up the list of reasons why things break than you would believe.
You have 1000 servers. You need to upgrade them to RHEL 6. Do you put a DVD in each of 1000 DVD drives?
NO!
You use an image server. Kickstart. Cobbler. Figure out how the new image looks like, and then pxeboot 1000 servers. That goes much faster. (to the sysadmin above, reimaging a server should take 25 minutes, most of which is spent surfing slashdot, not an hour).
So now, you've got a server that's misbehaving. One of 1000. Out of pure coincidence, honest, the one server you were manually futzing with last week, but that can't possibly be connected. Fixing that server yourself will cause more "configuration drift", and leave you with one server that's still different than the 999 other servers. And hey, that image server is still on your network. Just reimage the thing.
It's popular because it's the answer that scales. kthxbye.
The user would be none the wiser if the user had never gone to that encrypted site before with that browser and stored the key. It's the SSH trust model, only with a bad rap.
I believe your delusion is thinking that the people pirating your music actually searched for it. Rather, the odds are good that they did broad search, and then downloaded everything. After all, they were already at the relevant web site, they'd already downloaded one thing, the marginal cost (in time at the keyboard) of downloading everything was pretty close to zero. And hey, while they had never heard if it, what's the hard in giving it a try.
So they did. And then never bothered listening to it again.
I don't have any advice for you, other than better advertising. DRM doesn't work, and converting someone who pirated it to a buyer only works for subsequent releases.
But the kids who downloaded it from the Pirate Bay? They aren't your customers, and those are not lost sales. They wouldn't have bought it anyway, so you're not really losing money from them.