What I'm suggesting is significantly different. More like "talk like a pirate day" (or stupid and less fun "earth hour" thing). More publicity. So hopefully more people would be aware of what is going on.
Going below the speed limit in the fast lane is obstruction. In that case the driver should be "fixed". Going at the speed limit can be obstruction too, but if it is, then the speed limit should be fixed, or even removed completely.
> Maybe one day I'll simply stop in the road and refuse to cross the yellow line
Y'know, I've been wondering if we could have a "Follow the speed limit day", where people actually follow speed limits they think are stupid, just for that day.
The idea is to show how broken certain speed limits are. Maybe the people in charge of speed limits will change them when they get stuck in the resulting jam for hours.
If the problem is yellow lights that are too fast, fix that.
Removing cameras isn't going to stop the "one cop town speed trap" mentality. If they're willing to rig yellow lights (and kill people) just for $$$, they'll just find another way to collect money from you.
So using that as an excuse to remove the cams is silly and doesn't deal with the real problem.
I'm fine with removing traffic light cams as long as there's a much better reason.
You could end up which a few huge chunks of mischief versus many small pieces of mischief.
And that might not really be that much better.
The difference being that you, the small guy, can't afford to bribe your way out of stuff (or into stuff;) ), whereas the really rich ones can.
One nuke can be more damaging than a thousand bullets.
As long as some people can afford to bribe, the $$$/damage ratio matters more than the $$$ value.
Anyway, what appears to happen is the legislators just make stuff "legal", and voila it's officially no longer corruption and bribery. To me that's the worst form.
Actually someone I know used to work in a Swedish company (I think), and out of habit he was staying in the office later than the rest.
After a few days, one of the bosses asked him whether anything was wrong- whether he lacked training, or there were other problems so he couldn't finish his stuff on time, stuff like that.
To me, working is good, but it's not much point spending most of your life at work (even if you enjoy it a lot, there should be some balance). Computers should be doing that 24/7 stuff anyway, not humans.
The reality is there is actually a business case for Big Media to discourage adoption of IPv6.
When the ISPs start putting everyone behind NATs, it sure makes P2P a lot harder. It makes the internet start to look like a typical Big Media broadcast network - only a few authorized talkers, and many listeners. They like that sort of world.
In case someone asks, no you can't use stuff like uPnP, because you DON'T control the NAT device in that scenario, the ISP does.
The other thing is there is NO WAY an IPv4 only server can talk with an IPv6 only client, unless someone provides a NAT or Proxy device.
This will be a big problem as long as there are a lot of IPv4 only sites out there - ISP customers cannot be given just an IPv6 address. The ISP will have to either provide the customer with an IPv4 address (but they're running out of that), or force them to share one with NAT/proxying.
So, in the real world you are going to need to do NAT, since the odds of everyone switching to IPv6 for your convenience = zero.
Between paying for untested IPv6 proxy/nat/translation devices, and well tested IPv4 stuff, it's going to be easier to go IPv4 NAT.
If you're keeping private forks, maybe you could try git for that. svn is not so good for having lots of private versions.
I often did have to help to fix other people's stuff too. Or workaround them. There was a case where a range of set top boxes were broken and not passing DHCP broadcast replies to Vista machines (Vista requests for dhcp broadcast replies by default), if the ethernet broadcast address was used (ff:ff:ff:ff:ff:ff).
It was too hard to get the vendor to fix hundreds of buggy set top boxes at customer sites (it's really their fault though so they should have fixed it).
The workaround I came up with: add an option to send a dhcp reply frame with a IP broadcast address (255.255.255.255), but the ethernet unicast address of the dhcp client (vista machine). The DHCP RFC doesn't really say you can't do that, but, it doesn't say you can do that either;).
Yeah some of that stuff is what I try to figure out how to do when learning a new language.
But there's a few more things I'd add: signal and exception handling, logging, process control and management.
I found these also important for my programs. While you should be able to do these in most languages, the details sometimes get in the way of actually doing it:).
There's another thing to learn - the conventional or idiomatic way of doing "usual" stuff in the new language. Often there's more than one way to do something, but if you do it in some unexpected way, it makes it harder for others.
While the usual language tutorials might be nice, they are often useless for teaching "how the top programmers in this language like to do important real world stuff". So it's helpful if you can get hold of real life source code examples of what people consider as good code.
BTW it seems I disagree with at least one popular convention. The convention when daemonizing a program seems to be you direct stdin, stderr and stdout to "/dev/null/" (close then reopen them to/dev/null).
I on the other hand prefer to direct stderr and stdout to a log. Because daemon programs should NOT be sending anything to stderr and stdout. So if something is leaking out, it means there's a bug somewhere (whether in your code or someone else's code).
I've found it easier to find those bugs when stuff goes to a log than when it goes to "/dev/null/".
You may find out the "tag/label" or "search key" that's used to look for the instructions, but you might not find out the actual instructions if they aren't released yet.
The instructions will likely be signed.
While you can fix a few zombie so they accept your instructions, you'd have to fix the other thousands of zombies out there, if you want to do the same to them.
If the instructions are "shared" via the P2P network, it will make it harder to find out where they originate from.
Well it's amazing how none of the O/S devs got around to fixing it in 10 years.
It's not as if nobody noticed - the rest of us were working around that with noatime and similar stuff.
Sometimes I wonder if there are people going about looking for ridiculously pathetic stuff like that, and working to get them fixed.
Another example - for years the hardware people did not create an easy way for the software people to do "gettimeofday" on desktops. The hardware people were telling the software people - no don't use readtsc (and the early AMD X2 and opterons had probs with the TSCs of the different cores being out of sync). But there was nothing really better. The other options were either far more expensive in processing terms - many more cycles, or they were not standard built-ins on every PC/server. And guess how often software needs to check "hey is it time to do X yet?". So what's been done to improve that? I don't know.
Thing is, the CPU people can put so many transistors per die, but they don't seem to know what else to use them for and end up using most of them for cache. I figure someone should get a bunch of really smart software people to sit down with the hardware guys and figure out what annoyingly stupid stuff can be made better with those transistors.
Better locking? Easier threading? Maybe there's a good hardware way to make it easy and elegant to write code to handle thousands of concurrent connections (see: C10K problem http://www.kegel.com/c10k.html )? I dunno, but there must be more than just "let's just use it all for a 6MB cache, or lets just have more SIMD stuff".
How about use a different stack for return addresses and another stack for parameters/data? This might make it harder for hackers to "run arbitrary code of their choice" (that said, some data parms could actually be pointers to code...).
Only the stimulus bill to be approved this week, the $700 billion Troubled Asset Relief Program passed four months ago and $168 billion in tax cuts and rebates enacted in 2008 have been voted on by lawmakers. The remaining $8 trillion is in lending programs and guarantees, almost all under the Fed and FDIC. Recipients' names have not been disclosed.
Here everyone, look at the wookie's little friend. Oh you'd rather look at the wookie? That's OK too!
Even if it is just the folders being touched, with SSDs it means small blocks will be written when launching apps or opening files.
That will cause slowdowns for SSDs with high write latencies.
You can check the percentage for your usage, start perfmon.msc and add the relevant counters e.g. disk writes/sec and disk transfers/sec. Then do your real world stuff.
There's another thing you might want to do, to workaround the problem.
In Windows NT/2000/XP, Linux, FreeBSD and a few other operating systems, the O/S by default writes to the drive on every file/directory access to update the "Last Accessed Time".
This means the O/S will write stuff every time it opens a directory or file, even if it's just for reading!
This is bad for drive performance whether "conventional HDD" or SSD. And extremely bad for the crappier SSDs that don't do writes well.
You can turn that "insanity" off but at the risk of screwing up some apps/stuff (badly designed apps IMO).
For Windows: create a DWORD called HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate and set it to 1
For Linux: you can mount filesystems with "noatime", however this is incompatible with some applications (e.g. mutt). Fortunately for newer versions of Linux you can use relatime (which might already be the default on recent distros), which should reduce the amount of writing.
Note/warning: Do this at your own risk, YMMV, blahblahblah.
All I can say is "WORKSFORME" - so far I haven't noticed any probs with the Windows/Linux programs that _I_ use just because Last Access times weren't updated.
I believe there are different breeds of humans with different tendencies and traits, just like there are different breeds of dogs.
Plenty of scientific evidence for that.
Some breeds of humans are more prone to certain diseases, and other breeds are prone to a different set.
Now human breeds may not be as distinct as in dog breeds - we probably more mutts or mongrels in comparison. But they are still there due to generations of "selection" (via isolation, genocide, racism etc).
Call me cynical, but whether people use race or culture, or some other new term, it makes no difference. It's trivial to get people to think "Us vs Them". And it'll always be useful for leaders to get people to do so.
Yeah, people like Maddof should most certainly go to jail for a long time.
If we are just going to fine and confiscate money from people who do nonviolent financial crimes, it does not discourage them much, there are so many ways of siphoning the money off and hiding it.
Prison works. Even if you are a billionaire, 10 years in prison is 10 years out of your life, 10 years of opportunity cost. You might be able to afford some lifespan extension treatments, but I doubt you're even going extend it to 150 years with existing tech.
When are these long, redundant and stupid arguments about units every time a story mentions "degrees" going to die?
Yes this is a nerd site. So use your brains to figure out what unit is being used, then use Google or something to convert if necessary.
If the US people want to use Fahrenheit let them.
IIRC people working for Verizon had problems with decimal places, dollars and cents[1]. So maybe it's better to avoid scary/confusing stuff like "23.5" on US air conditioners.
Why not just change your password? Even if it's not in that particular document, it might be in other similar documents, this might not be a one-off mistake.
Or are you trying to figure out whether you can sue them?;)
Slashdot Mirror
Yeah, the metadata was written first, then only ext3 was actually created.
A filesystem that writes the metadata before the actual data, is a "Duke Nukem Forever" Filesystem.
Not at all.
What I'm suggesting is significantly different. More like "talk like a pirate day" (or stupid and less fun "earth hour" thing). More publicity. So hopefully more people would be aware of what is going on.
Going below the speed limit in the fast lane is obstruction. In that case the driver should be "fixed".
Going at the speed limit can be obstruction too, but if it is, then the speed limit should be fixed, or even removed completely.
> Maybe one day I'll simply stop in the road and refuse to cross the yellow line
Y'know, I've been wondering if we could have a "Follow the speed limit day", where people actually follow speed limits they think are stupid, just for that day.
The idea is to show how broken certain speed limits are. Maybe the people in charge of speed limits will change them when they get stuck in the resulting jam for hours.
If the problem is yellow lights that are too fast, fix that.
Removing cameras isn't going to stop the "one cop town speed trap" mentality. If they're willing to rig yellow lights (and kill people) just for $$$, they'll just find another way to collect money from you.
So using that as an excuse to remove the cams is silly and doesn't deal with the real problem.
I'm fine with removing traffic light cams as long as there's a much better reason.
You could end up which a few huge chunks of mischief versus many small pieces of mischief.
;) ), whereas the really rich ones can.
And that might not really be that much better.
The difference being that you, the small guy, can't afford to bribe your way out of stuff (or into stuff
One nuke can be more damaging than a thousand bullets.
As long as some people can afford to bribe, the $$$/damage ratio matters more than the $$$ value.
Anyway, what appears to happen is the legislators just make stuff "legal", and voila it's officially no longer corruption and bribery. To me that's the worst form.
Actually someone I know used to work in a Swedish company (I think), and out of habit he was staying in the office later than the rest.
:).
After a few days, one of the bosses asked him whether anything was wrong- whether he lacked training, or there were other problems so he couldn't finish his stuff on time, stuff like that.
To me, working is good, but it's not much point spending most of your life at work (even if you enjoy it a lot, there should be some balance). Computers should be doing that 24/7 stuff anyway, not humans.
But of course, I'm a lazy person
The reality is there is actually a business case for Big Media to discourage adoption of IPv6.
When the ISPs start putting everyone behind NATs, it sure makes P2P a lot harder. It makes the internet start to look like a typical Big Media broadcast network - only a few authorized talkers, and many listeners. They like that sort of world.
In case someone asks, no you can't use stuff like uPnP, because you DON'T control the NAT device in that scenario, the ISP does.
The other thing is there is NO WAY an IPv4 only server can talk with an IPv6 only client, unless someone provides a NAT or Proxy device.
This will be a big problem as long as there are a lot of IPv4 only sites out there - ISP customers cannot be given just an IPv6 address. The ISP will have to either provide the customer with an IPv4 address (but they're running out of that), or force them to share one with NAT/proxying.
So, in the real world you are going to need to do NAT, since the odds of everyone switching to IPv6 for your convenience = zero.
Between paying for untested IPv6 proxy/nat/translation devices, and well tested IPv4 stuff, it's going to be easier to go IPv4 NAT.
If you're keeping private forks, maybe you could try git for that. svn is not so good for having lots of private versions.
;).
I often did have to help to fix other people's stuff too. Or workaround them. There was a case where a range of set top boxes were broken and not passing DHCP broadcast replies to Vista machines (Vista requests for dhcp broadcast replies by default), if the ethernet broadcast address was used (ff:ff:ff:ff:ff:ff).
It was too hard to get the vendor to fix hundreds of buggy set top boxes at customer sites (it's really their fault though so they should have fixed it).
The workaround I came up with: add an option to send a dhcp reply frame with a IP broadcast address (255.255.255.255), but the ethernet unicast address of the dhcp client (vista machine). The DHCP RFC doesn't really say you can't do that, but, it doesn't say you can do that either
"error can now try to fill up your hard drive "
/dev/null. I don't see how that's a good idea.
:).
That's a feature! It makes the error easier to detect.
Why have the error fill
Just because nobody sees the errors doesn't mean there isn't a bug.
I prefer to reach a "low bug" state ASAP. Gives me more time waste on Slashdot and other silliness
So far most (all?) of the stuff going into the logs are due to bugs in other people's code (libs, modules etc).
Yeah some of that stuff is what I try to figure out how to do when learning a new language.
:).
/dev/null).
But there's a few more things I'd add: signal and exception handling, logging, process control and management.
I found these also important for my programs. While you should be able to do these in most languages, the details sometimes get in the way of actually doing it
There's another thing to learn - the conventional or idiomatic way of doing "usual" stuff in the new language. Often there's more than one way to do something, but if you do it in some unexpected way, it makes it harder for others.
While the usual language tutorials might be nice, they are often useless for teaching "how the top programmers in this language like to do important real world stuff". So it's helpful if you can get hold of real life source code examples of what people consider as good code.
BTW it seems I disagree with at least one popular convention. The convention when daemonizing a program seems to be you direct stdin, stderr and stdout to "/dev/null/" (close then reopen them to
I on the other hand prefer to direct stderr and stdout to a log. Because daemon programs should NOT be sending anything to stderr and stdout. So if something is leaking out, it means there's a bug somewhere (whether in your code or someone else's code).
I've found it easier to find those bugs when stuff goes to a log than when it goes to "/dev/null/".
It might just look for new instructions.
You may find out the "tag/label" or "search key" that's used to look for the instructions, but you might not find out the actual instructions if they aren't released yet.
The instructions will likely be signed.
While you can fix a few zombie so they accept your instructions, you'd have to fix the other thousands of zombies out there, if you want to do the same to them.
If the instructions are "shared" via the P2P network, it will make it harder to find out where they originate from.
Well it's amazing how none of the O/S devs got around to fixing it in 10 years.
It's not as if nobody noticed - the rest of us were working around that with noatime and similar stuff.
Sometimes I wonder if there are people going about looking for ridiculously pathetic stuff like that, and working to get them fixed.
Another example - for years the hardware people did not create an easy way for the software people to do "gettimeofday" on desktops. The hardware people were telling the software people - no don't use readtsc (and the early AMD X2 and opterons had probs with the TSCs of the different cores being out of sync). But there was nothing really better. The other options were either far more expensive in processing terms - many more cycles, or they were not standard built-ins on every PC/server. And guess how often software needs to check "hey is it time to do X yet?". So what's been done to improve that? I don't know.
Thing is, the CPU people can put so many transistors per die, but they don't seem to know what else to use them for and end up using most of them for cache. I figure someone should get a bunch of really smart software people to sit down with the hardware guys and figure out what annoyingly stupid stuff can be made better with those transistors.
Better locking? Easier threading? Maybe there's a good hardware way to make it easy and elegant to write code to handle thousands of concurrent connections (see: C10K problem http://www.kegel.com/c10k.html )? I dunno, but there must be more than just "let's just use it all for a 6MB cache, or lets just have more SIMD stuff".
How about use a different stack for return addresses and another stack for parameters/data? This might make it harder for hackers to "run arbitrary code of their choice" (that said, some data parms could actually be pointers to code...).
There at least some public debate about the 700 billion.
How about the 9.7 trillion? 9.7 trillion is a lot bigger than 700 billion.
http://www.bloomberg.com/apps/news?pid=20601087&refer=home&sid=aGq2B3XeGKok
Only the stimulus bill to be approved this week, the $700 billion Troubled Asset Relief Program passed four months ago and $168 billion in tax cuts and rebates enacted in 2008 have been voted on by lawmakers. The remaining $8 trillion is in lending programs and guarantees, almost all under the Fed and FDIC. Recipients' names have not been disclosed.
Here everyone, look at the wookie's little friend. Oh you'd rather look at the wookie? That's OK too!
Even if it is just the folders being touched, with SSDs it means small blocks will be written when launching apps or opening files.
That will cause slowdowns for SSDs with high write latencies.
You can check the percentage for your usage, start perfmon.msc and add the relevant counters e.g. disk writes/sec and disk transfers/sec. Then do your real world stuff.
There's another thing you might want to do, to workaround the problem.
In Windows NT/2000/XP, Linux, FreeBSD and a few other operating systems, the O/S by default writes to the drive on every file/directory access to update the "Last Accessed Time".
This means the O/S will write stuff every time it opens a directory or file, even if it's just for reading!
This is bad for drive performance whether "conventional HDD" or SSD. And extremely bad for the crappier SSDs that don't do writes well.
You can turn that "insanity" off but at the risk of screwing up some apps/stuff (badly designed apps IMO).
For Windows: create a DWORD called HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate and set it to 1
For Linux: you can mount filesystems with "noatime", however this is incompatible with some applications (e.g. mutt). Fortunately for newer versions of Linux you can use relatime (which might already be the default on recent distros), which should reduce the amount of writing.
Note/warning: Do this at your own risk, YMMV, blahblahblah.
All I can say is "WORKSFORME" - so far I haven't noticed any probs with the Windows/Linux programs that _I_ use just because Last Access times weren't updated.
"the problem is that you can not access the actual flash chips "
I don't see that as a problem. In fact I see that as a good thing. Otherwise think of all the buggy custom drivers you would be plagued with.
I'd rather the SSD manufacturers improve the technology so that the O/S doesn't have to know about such stuff.
What's important to have is stuff like "make sure data is flushed to nonvolatile storage", features that will remain important for decades to come.
No he said: "they will get rid of SHOWERS."
Doing a Godwin would be: In Nazi Germany, SHOWERS get rid of YOU!
I believe there are different breeds of humans with different tendencies and traits, just like there are different breeds of dogs.
Plenty of scientific evidence for that.
Some breeds of humans are more prone to certain diseases, and other breeds are prone to a different set.
Now human breeds may not be as distinct as in dog breeds - we probably more mutts or mongrels in comparison. But they are still there due to generations of "selection" (via isolation, genocide, racism etc).
Call me cynical, but whether people use race or culture, or some other new term, it makes no difference. It's trivial to get people to think "Us vs Them". And it'll always be useful for leaders to get people to do so.
What you do is have YOUR hypervisor running first.
Then their hypervisor is stuck in your Matrix, not the other way round.
Regarding COD nowadays. I doubt most honest and sane people would like to be the postman carrying the $$$$.
Crooks already rob pizza delivery workers.
Yeah, people like Maddof should most certainly go to jail for a long time.
If we are just going to fine and confiscate money from people who do nonviolent financial crimes, it does not discourage them much, there are so many ways of siphoning the money off and hiding it.
Prison works. Even if you are a billionaire, 10 years in prison is 10 years out of your life, 10 years of opportunity cost. You might be able to afford some lifespan extension treatments, but I doubt you're even going extend it to 150 years with existing tech.
If they aren't brand new the reason why it's cheaper is because someone else has paid for much of it.
When are these long, redundant and stupid arguments about units every time a story mentions "degrees" going to die?
Yes this is a nerd site. So use your brains to figure out what unit is being used, then use Google or something to convert if necessary.
If the US people want to use Fahrenheit let them.
IIRC people working for Verizon had problems with decimal places, dollars and cents[1]. So maybe it's better to avoid scary/confusing stuff like "23.5" on US air conditioners.
[1] http://verizonmath.blogspot.com/2006/12/verizon-doesnt-know-dollars-from-cents.html
Well maybe he could go before a jury of his peers, and say "I didn't do that, it must have been someone using my account".
And most of the jurors would believe him, since they'd have been phished/keylogged/pwned/comcasted[1] before or knew someone who had.
[1] Comcasting is the broadcasting of your usernames and passwords.
Why not just change your password? Even if it's not in that particular document, it might be in other similar documents, this might not be a one-off mistake.
;)
Or are you trying to figure out whether you can sue them?