If I were to pull the plug on a consumer grade mechanical hdd in the middle of a write, would it not lose data as well?
My only guess is that they're looking at it from the point of view of file system corruption with journaling filesystems, and whether or not stuff committed with sync() is actually safely stored on the drive at that point in time or not. However, the poor way in which the author describes this (assuming it's what he's attempting to describe at all) seriously makes me wonder why I should trust that he knows what the hell he's doing.
Some years ago while discussing design of a journaling filesystem with someone in a newsgroup, we were wondering whether sector writes to a hard disk could be expected to be atomic or not. Once a drive has begun writing to a sector, there's a very tiny amount of time it has to keep power in order to finish the sector, which would seem trivial to store in a capacitor, and with some added circuitry, the momentum in the spindle could supply some power as well. Not to mention that attempting to read a half-written sector is going to cause all sorts of hell for an algorithm that assumes there was a full sector there and so it should be able to error correct it into something meaningful, and might cause it to prematurely declare the sector dead and remap it. So it seemed a bit silly to think that a hard disk wouldn't be able to check its power status between sector writes and simply avoid beginning one which it wasn't going to be able to finish reliably, and this would allow someone to utilize this fact when designing a journaling filesystem since they could at least count on any sector they read to contain valid data even if they couldn't count on whether it was current data or old data. For example, each sector of the journal might have an index number allowing old entries to be distinguished from new ones without worry that the drive died half-way while writing the sector, thus causing it to begin with a recent index number but contain older data at the end. Of course, neither of us knew if this was true of how drives worked or not, but one random person took the time to reply simply "sector writes are atomic" for whatever a random person's word is worth.
Solid state drives have a similar issue in that once they begin rewriting their data structures, if they don't finish, then the data on the drive is going to be rather fucked, particularly since they don't work on sectors like traditional hard drives, but rather, each page of flash holds many sectors, and they're not even in linear order but instead there are wear-leveling algorithms in play. So even when the OS asks the drive to sync(), in the interest of speed, since it will have to combine the sectors written with other sectors and additional wear-leveling data before committing it to flash, it's likely in its interest to lie to the OS and say "OK, it's done" when in fact it's merely committing to writing those sectors before it shuts down even if power is cut immediately. Obviously there are a lot of ways to screw up such a commitment and be unable to deliver upon it, and I assume that's what the author of the article is testing.
...but, hell if I know. It'd be nice to hear from someone who actually knows about these things.
I might have to buy a few for myself too. They'll probably just sit in a box somewhere for quite a long time, but the simple fact is that while fluorescent works just fine for me, I do know that incandescent outputs light of all frequencies and so it is technically superior. So if at some point in the future I require that superiority, I want to have the option of using a simple and inexpensive piece of technology that provides it rather than having to search online for the latest and greatest florescent with the closest-to-incandescent-yet-still-not-ideal light output. They're also great for when you need a little bit of heat in a fairly safe form-factor.
The compact fluorescent bulbs are good, but banning the old bulbs is still stupid.
when was the last time you had a hard fault due to ecc parity error?
I've actually had two occasions which I think were the result of a single-bit error in my RAM. (Not exactly what you asked, but still relevant I think.)
On one occasion I was writing some code and got a compilation error in a file I hadn't even been editing. I opened it up and went to the line of the error and found a single character that was incorrect, and after wondering what the hell had happened, I eventually switched the editor to hex mode and realized that the character differed from the correct character by a single bit. I left it alone for a while, confused as to exactly what the hell had happened, and at first I had suspected a disk error, but it eventually occurred to me that the file was probably being read from cache and so it might well be a memory error. So I did something to use a lot of RAM in order to dump the file from cache, then reloaded it, at which point the error was corrected.
On the other occasion, a Linux system I'd been using for years without any issues spontaneously decided to hose itself, with the filesystem essentially committing suicide. One minute it was working and then everything just kind of started falling apart and a few minutes later it decided to remount the filesystem read-only. After that I shut it down to take a look at the drive in another machine, where I found the filesystem to be damaged beyond repair. I eventually found a recovery tool someone had made which spent hours scanning the drive trying to find indications of where the files may have been and was able to recover about 80% of them, but the remaining 20% were file names which contained data from some other file, or folders which were restored as ordinary files with some random data in them, or sometimes even symbolic links. Granted, this sounds a lot more like a random fuck-up by the filesystem driver than anything else, but it'd been at least a year since I'd installed the particular version of Linux I was using and it'd always worked fine before that, and it didn't seem to be a hardware issue either as the same hardware has continued to work fine for years since then. Thus, I can only conclude that just the right bit happened to get flipped to cause the filesystem driver to lose its mind, e.g. a flipped bit in its instruction code changed it in such a way that it didn't crash, but it no longer properly manipulated the filesystem data structures either....and there may well have been other computer problems I've had in the past which were due to memory errors that I just didn't realize at the time. I used to always consider my computer to be a machine which simply never made mistakes in its calculations, and so when something went wrong it was always the software's fault, but I changed my views after trying to install Gentoo on one particular computer and having the install die with a compilation error. While searching the internet for the cause, I found a forum thread about similar errors which suggested that the problem may be the hardware, and as a simple test, suggested simply running the compile again to verify that the error is identical. So I ran it again, and got a completely different error. Then I tried yet again and got a third completely different error. So I took the machine apart and blew the dust out of the CPU heat sink, and after that it worked just fine. Apparently the Gentoo folks have to deal with a lot of bug reports that are the result of hardware errors, since their many compiles are often the hardest and most sustained work that your average PC ever sees.
You probably get more hardware errors than you realize. It's just that, given how software tends to crash now and then, it's far easier to assume it was merely the software's fault that it did whatever it did, rather than to consider that maybe your hardware makes some extremely rare errors.
Being poor, I still have no ECC memory, but I'd love to have some if it weren't so expensive.
Do you actually work for the NSA or do you just have an addiction to cool aid?
I'm actually in disbelief that anyone has taken my suggestions seriously. Someone even modded it "troll." It was just a random idea that popped into my head as I was writing the post which I found too amusing, in a conspiracy theory sort of way, to not mention. It shouldn't be taken any more seriously than that.
They make the all too common mistake of believing that 'literally' is just an emphatic and 'categorically' is a stronger emphatic.
This thought crossed my mind as well. No one bothers to learn what words mean before using them. I make it a point to ask for a definition whenever anyone uses a word I don't know, and amusingly enough they almost always give a definition that even I know isn't correct. I had to look up "categorically" after reading it in their statement, and so, being one of those words, it wouldn't surprise me to learn that the author doesn't actually know what the word means.
They're lying because the truth would be the end of the company
...and that's kind of my point.
I mean, it's like if Alice killed Bob's dog, and everyone on Slashdot suspects her of it, and points to her twitter feed where she's written "I have no idea where Bob's dog is" as evidence, because they think she's being evasive by not saying "I didn't kill Bob's dog" because she probably tossed it in a dumpster last week and so she technically doesn't actually know where it is now. It'd be pointless for her to post truthful statements that sound like denials because no one is going to care that she didn't lie about it if, in the future, a security camera video surfaces of her dumping the body in a dumpster behind Wal-Mart. So why would she risk the suspicion caused by evasive statements when she could instead use direct lies like "I did not kill Bob's dog" and avoid the unnecessary suspicion they create?
This is why I think it's a bit silly to pick apart RSA's statement as if we're going to dig out some hidden meaning. They certainly didn't just mean to imply that they didn't do it without actually telling any lies. They meant what they appear to have said and apparently just didn't anticipate that people might try their best to misunderstand them. People who betray their customers for cash aren't going to be worried about being caught lying to them as well. So either they did it and they're lying about it, or they didn't do it and they're not lying about it. Either way, assuming their statement has some secret meaning other than "we didn't do it" seems ridiculous.
every system that can access plain text can access binary as well.
True, but it should use fewer cycles and fewer amp hours for the ARM system to translate the textual intermediate representation to x86 or ARM instructions than to translate an x86-64 binary to an intermediate representation and then to x86(-32) or ARM instructions.
Binary doesn't necessarily mean instruction code for any particular processor. Is this why people insist on text so much, because they've come to equate the word "binary" with "compiled executable?"
You certainly wouldn't want it to be x86 code anyway, as modern operating systems lack proper security measures to make running untrusted x86 code a good idea. You'd want a pseudo-bytecode which simply indicates operations to perform and you'd translate that into your native machine code, or just run an interpreter on it. The pseudo-bytecode would be designed such that it cannot even represent operations you don't want your untrusted code to perform and so, as long as your programmers aren't completely inept, converting it to native code and running that would be relatively safe.
Also, compiler-enforced memory safety seems like an accident waiting to happen.
How is memory safety enforced in a compiler more of "an accident waiting to happen" than the same enforced in hardware, which is the source of the terms "segfault" and "general protection fault"? Other than that Oracle has had a poorer track record than AMD and Intel, that is.
Well, first of all, have you ever known your CPU to fail to trigger a segmentation fault when a program performs an invalid access? So it's 100% effective then, right?
What we're concerned about is not detected accidents, but undetected ones. Like when someone finds some way to write a statement that performs something which isn't allowed but which the compiler fails to notice due to the unusual syntax of the statement. In binary form there's only so many ways you can describe an operation. In text there are far more due to there generally being no rules about whitespace, variable name length, the number of digits in your numbers, and many other things. So by using plain text you greatly increase the number of opportunities you have to screw up. That's just fine if you're one of those programmers who believes you'll never accidentally code a buffer overflow into your software, but if you're realistic and realize you're only human, then you realize the wise thing to do is to design a system that's as simple as it can be so that you give yourself as few opportunities to fuck it up as you can.
I mean, technically you can drive your car from the back seat just by sticking your ten year old in the driver's seat and telling them when to turn the wheel, and with some luck you may even be able to do this rather well, but it's a scheme that's more likely to result in disaster than simply sitting behind the wheel yourself, and so you just don't do it that way.
so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.
How is this any less true of images, audio, video, or any other content type on the World Wide Web?
It's not, and the fact that one particular browser exploit I remember involved using "width" and "height" tags on images with values prefixed with 64k zeros, I think it demonstrates my point rather well. We've been parsing text since the beginning of computing and it's still something we regularly fuck up all the time. We should avoid doing it whenever we don't have to do it, and when we do have to do it, we should do it on a machine under the control of the person who supplies the text, since if they hack themselves no one gives a shit.
As for audio and video, they of course include some variable length buffers, but it's k
However, what is the point of ignoring something which the average person spends about 10% of their monthly income on?
I only want to ignore it when trying to track the changing value of a currency because its price is particularly likely to change for reasons that have nothing to do with changes in the value of the currency. It certainly has a lot to do with cost of living, however, and so it should be included when trying to calculate that. At least until other energy alternatives are not only more cost effective but also easily utilized by the average consumer instead of oil, or until we all decide that driving everywhere isn't an essential part of life.
If Wikipedia is to be believed, the CPI's purpose is to track inflation, not to track cost of living, and so they'd be correct to exclude it, but then "consumer price index" would seem to be a bit of a misnomer. The article also seems to say that mortgage rates are included, which to me would seem to be an item that wouldn't accurately reflect inflation, particularly if we have the Federal Reserve adjusting interest rates in order to control inflation according to what we measure it to be using the CPI (if that's how they do it) since that creates a feedback loop. I'd guess it suffers from lack of a clear goal, and so everyone wants to include or exclude certain things depending on what they imagine the CPI should represent, and so it's just another government clusterfuck which only manages to be useful simply because the number of people involved ensures that it can't go completely off track before too many people notice.
I can't say I disagree with businesses using a metric which tracks only inflation when performing such calculations either. Imagine the cost of oil just keeps going up, and for some reason our alternatives vaporize and so we have no alternatives to that higher price... It'd be wonderful if our employers could all just pay us more to compensate but that money has to come from somewhere. In reality we'd all either have to work harder to keep doing the same things (as that increase in the cost of oil represents an increase in the work necessary to produce it) or we'd have to adapt to a lifestyle that doesn't require so much oil.
On the other hand, increases in wages to match inflation are to be expected. Your work has a certain value, and you expect to be compensated for that value, but our money slowly declines in value by design. So if your wages don't increase with inflation then you're getting the opposite of a raise, which is a "lower" I guess. A raise that merely matches inflation isn't a raise at all....and that may be why companies don't like to give automatic raises according to inflation. If they don't have an official policy of doing so, then they can pass off such raises as an actual increase in pay, and most people, being largely unaware of inflation, will see it as such.
I have a friend who every year has a talk with his boss about what his pay needs to be, and is certain to point out that if it doesn't increase to match inflation then his boss is telling him that he's not worth as much to him this year as he was last year. It seems to work for him, as does his apparent philosophy that one should never stop looking for better employment, as he makes more money than anyone I else I know. I don't know if he spends an hour a day looking for jobs or what, but from what I've seen, over the years that hour a day has earned him more money than all of the hours he spends at work as he's managed to double his pay by constantly finding a new employer to pay him 10% more than the previous one.
Well, we could pick at their wording, but assuming we take their use of the word "categorically" to mean what the word means, it's rather hard to suggest that they intended to say anything other than what their statement says on the surface: it didn't happen.
Obviously they could be lying, but so could Reuters, or maybe Snowden forged the documents, or maybe Reuters simply misunderstood them, or maybe it's just some sort of bullshit NSA internal documentation intended to mislead any spies who happen to steal the information. (...and it did get stolen, which almost seems to kick that last idea into the realm of possibility.)
Hell, now that I think about it, that might also explain Google et. al.'s denial of their involvement with the NSA as well. I mean, if you can't actually spy on everything your enemies do on the internet, you might just settle for convincing them that you can, so that they're afraid to use the internet and are therefore at a disadvantage by not utilizing a valuable tool. It might also cause them to choose methods of communication that you can easily monitor.
Maybe Edward Snowden stole a honeypot. Wouldn't that just be hilarious? Has he revealed anything that's independently verifiable?
In theory, the text can be translated to x86, ARM, or any other 32- or 64-bit architecture, and the translator enforces some memory safety guarantees.
...and in reality, your text is transmitted in binary, as a series of bytes, using an encoding known as ASCII, which means that every system that can access plain text can access binary as well.
Also, compiler-enforced memory safety seems like an accident waiting to happen....but then, so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.
The "everything must be a web site" mentality has confused the hell out of me for ages as well.
For some time I assumed it was probably for portability, but while writing a game I'm sure no one cares about I found that portability actually isn't all that difficult. The number of #ifdef involved to make it compile for both Windows and Linux (and FreeBSD, though I haven't compiled for it in about a year) amount to a very minor part of the code, and probably wouldn't have been even that much if I were more of a fan of using other people's libraries. (It does use GLFW, which no doubt is taking care of at least 95% of the portability issues for me.) I suspect even a Mac OS version wouldn't be too difficult though I never could figure out how to produce one from Linux. Granted, I don't have a reliable Linux version available due to LGPL issues, but no one cares about Linux anyway. They could certainly achieve portability between the platforms they care about (anything Windows runs on, and Mac OS) easily enough with a compiled C program, and if they really cared they could also set up a server farm of Linux machines so that they have a copy of each distribution available to compile a Linux version too.
So then why is it I go to YouTube and deal with shitty web video that barely plays correctly if it does at all? I've seen the red and blue channels reversed in video, I've seen 30-second seek times (even seeking backwards), and at times it simply doesn't work at all. The same goes for hulu.com or any online radio web site. Even Facebook could benefit from having a custom application....and all of these things would run more efficiently as an application than they do as a web site.
Hell, the new flickr.com is probably the best example. In their desire to have a wall of images in the search results, the javascript spends so much time examining possible arrangements of the images that the computer grinds to a halt. The web site is damn-near unusable, and certainly only "usable" if you're desperate. As far as "I'm bored so I'll look for something interesting on Flickr" goes, it's positively worse than being bored. Granted, they should do the intelligent thing and just go back to the web site they had, but as long as they're insistent on styling their image indexes like that, if they were to do it in a custom application, it could figure out the arrangements it wants in the blink of an eye and so the user experience wouldn't be so miserable.
The craziest thing about it for me is that, given the choice between making a web site and making a proper application, I'd rather make a proper application. Communicating with a server over a TCP connection is a piece of cake, so I don't need a web browser for that, nor do I want to structure everything as an HTTP request anyway. I also don't have to worry about cross-testing in every version of every web browser. Granted, you do then have to cross-test to different operating systems, but at least between Windows and Linux, I've found most of the issues that crop up tend to be data access errors that show up in one version but not the other simply due to data being arranged differently in each executable, and I haven't even seen that since compiling with -fstack-protector-all and writing a wrapper for malloc() in an effort to catch any invalid data access. With web sites I always seem to spend at least 20% of my time trying to make things look at least reasonable in every web browser, and I'm not one of those people who even tries to do fancy shit, I just keep running issues into things like one web browser inserting a blank line somewhere where another doesn't and trying to figure out some way to structure everything so that, if they can't all look the same, then at least none of them end up with ass-ugly formatting.
So I can only guess that the "everything must be a web site" is a user-driven demand.
Part of that might be the Windows convention that no matter how trivial
Bitcoin is fluctuating in value right now precisely because people are betting on its future usefulness as a currency.
Actually, they're merely betting on its future value. This idea that the value of a bitcoin is related to the usefulness of a bitcoin is false. It's merely an effect of supply and demand, to which usefulness is a factor, but hardly the only one, and probably not even the largest one at present.
Are dollars any less useful today than they were a hundred years ago, despite the much lower value they have today? The value of a currency is irrelevant to its usefulness. If it's worth less, then you're simply paid more of it for your work, and you pay more of it for things you want. If it's worth more, then you're simply paid less of it for your work, and you pay less of it for things you want. The value is in work and in property, the currency is just a measure, like meters and feet. You'll note that the length of a meter has nothing to do with it's usefulness of a unit of measure, and it would be useful as a unit of measure no matter what its length, just so long as its length is constant over space and time.
That's kind of what's driving this insane deflation Bitcoin is seeing. People want to invest in it, and so they decide how much they want to invest, say $100, and then they buy $100 worth of bitcoins, however many that is at the moment. It doesn't matter to them how many they get since the value of the currency is simply what they expect to exchange it for in the future, and they expect that to be more than they exchange for it in the present. Indeed, I guarantee you they're all looking at it not as "now I own 0.15 bitcoins" but rather "now I own $100 of bitcoins" -- bitcoins themselves are such a poor measure of value that people measure the number of bitcoins they have in terms of another currency rather than in terms of bitcoins because "0.01 bitcoins" doesn't hold any meaning to anyone because what it means changes far too often to be worth learning.
The same thing is certainly going on with gold. Is that 1 gram of gold really worth $50 to you? If so, it's probably only because you can exchange it for $50, not because you have anything you can do with it that you feel is worth its $50 cost. The same is true of bitcoins, but even worse because bitcoins are ultimately useful for nothing other than exchanging for other value, and people don't end up holding some small piece of metal in their hand wondering "why did I pay $50 for this?" They're told that 0.075 bitcoins are worth $50 and so they're worth $50 to them.
Dollars are really no different in that regard. What makes them different is that their value is regulated by the Federal Reserve. Bitcoin's (and gold's) value will vary depending upon supply and demand. Dollars would do the same thing, but the federal reserve regulates the value by changing the interest rate it charges for loans on money it creates out of thin air (or, actually, cotton). When it wants the value of a dollar to go down, it lowers the interest rate, so people are more easily able to acquire money and so the value goes down. When it wants the value to go up, it raises the interest rate, making money harder to acquire, and also pulling money back out of existence as the previous loans are repaid and not renewed and so that money is destroyed. The result is that supply and demand can be factored out of the currencies value, and it can become useful as a measure of value, since its most important quality in measuring value, like the meter, is that the measurement is stable over time. Bitcoin, of course, has no such mechanism in place, and so the value is always going to fluctuate randomly. It may become more stable over time as it sees more use, but whereas you can predict that dollars will see about a 4% annual inflation rate, and be worth about half what they are now in 20 years, you'll be unable to make any such predictions for bitcoin.
As for that inflation the federal reserve creates, I su
I'm not sure that comparing costs of anything oil-based is really fair. The idea of judging currency based on how much it buys is that you want to choose commodities which have the same value over time, but oil isn't known for being stable. It's not far off from judging inflation by tracking the cost of bitcoins. (well, actually it is -- bitcoins are quite unstable) Cars aren't necessarily fair game either since safety standards change over the years, and given that a higher investment in a car can save you money over the long term in fuel, such technology arriving can cause car prices to increase by consumer demand as they want what that increased cost pays for, meaning that the cost increase isn't an actual cost increase, but instead it's consumers choosing to buy more than what they were buying before.
That's why these things are usually done via average of the cost of many different things, and exclude things known to vary in price a lot.
Anyway, from what little I can remember of the past, I've noticed that common payments for simple fixed-cost utilities (like telephone, cable bill, internet -- things you could do without if you wanted) way back in the late-eighties were all basically $20 a month. Some time between then and now, I noted that they were all $40 a month. Now they all seem to be $60 a month. That's a 25 year time span, and the 25th root of 3 is 1.045, meaning the inflation I've observed in this case has been 4.5% per year. Certainly at the higher end of the 2-4% the GP mentioned, but within the range. Given that such prices aren't actually based on costs at all (they're all provided by monopolies), but rather what sort of value people feel comfortable disposing of for cool things they want, it's hard to say how reliable this is (and let's not forget the accuracy of my memory) but I suspect it's not a terrible measure.
Contrast that with bitcoin which a year ago was valued at $14 or so, and at the present moment is $661, which gives us a *monthly* deflation rate of 38%, which understates the issue by pretending it's a constant change, whereas it's really quite random.
Personally, I like the obsession with menu bars at the top and bottom. It ensures that applications aren't hungry for additional monitor width, which means I can actually run two of them side-by-side on the same monitor. If they start making use of that additional width then I'll no longer be able to do that.
Menus on the left or right also take up far more pixels than menus on the top or bottom simply because text is written left to right. So applications that use menus on the left or right easily eat away the additional width that comes with wide-screen monitors, putting us right back in the situation we were in with 4:3 monitors where most applications (particularly web browsing) are impossible to use without consuming the entire screen.
There is always this desire to make a Swiss Army knife. But you have to make compromises, and those compromises directly impact the capabilities as well as the cost of the robot.
...and the logical conclusion of that is to design the robot to do one specific task and it will do that task very well at minimal cost.
We already have things like that. We call them machines. While these "robot manufacturers" a.k.a. kids with too much money on their hands who want to pretend like they're investing it while they waste it away building cool toys... Anyway, while they like to sit around and imagine their robots that can lift a whole 3 pounds and move it at a mind-boggling 10 cm/s will find thousands of uses, I'd be a lot more impressed if they could give even one real-life example where employing their robots saves a company money and does so in a way where it isn't possible to save much more money simply by hiring workers or using a custom-built machine.
If a custom-built machine can handle those 3 pound objects a thousand times faster, then employing a thousand of those robots to do the same amount of productive work isn't a wise business decision, even if you can still be profitable, as that machine is probably going to cost you far less than $35 million. So using the robots has to not simply be profitable, but has to be at least in the ballpark of how profitable other methods are.
There are two stinky common problems with my game, both of which annoy the hell out of me, but neither of which I can really do anything about.
The first is issues with graphics rendering. It seems that, even though OpenGL has a way to report errors like "out of memory," a lot of graphics drivers simply don't bother to do so. Instead they just render shit incorrectly and generally fuck shit up. The result is that it looks like the game sucks, but the truth is the game isn't being told anything about what's wrong. It presently doesn't pay attention other than to report the errors on stderr, but then to my knowledge, nothing useful has ever come out of OpenGL's error reporting functions, so it isn't like I'm missing out on a chance to give useful information to the user. Indeed, the graphics stacks which don't have these problems seem to deal with low memory not by reporting an error, but by swapping things to system memory where, if memory usage goes up further, the OS begins swapping out to disk. Thus the good drivers just get slower when they run low on memory, but otherwise present no errors. The bad ones just randomly drop textures and display lists, and again present no errors.
The second is issues with malloc(). Sure, malloc() will tell you when it cannot allocate memory. The problem is that there's generally nothing you can do in that case other than to terminate the program. You can't even printf() about the error because printf() uses malloc() internally and so if malloc() isn't working, printf() won't work either. Nevermind trying to do something more reasonable like display a message to the user about what went wrong and what they might be able to do about it.
Unfortunately, many of the tools programmers rely upon to make software have been written lazily, and so even if you yourself write your code to detect as many errors as possible, there are still plenty you can't do anything about. My game checks the return value of everything. In most cases it just prints a message to stdout and exits, as many errors are just so unlikely that it isn't worth the trouble of writing code to do anything else. Even so, I still get malloc() errors that don't make sense. I made it track memory usage and found that malloc() fails after allocating 400 MB of data on systems with 4 GB and no other software running. I have no clue why it's happening, and I can't do anything about it after it happens. It'd be nice if malloc() were more informative about why it is failing than to simply return NULL as a generic error. I've thought about simply doing one huge malloc() for everything I need and then write my own memory allocator to allocate out of that chunk so that I can be guaranteed to get what I need, but even that doesn't solve problems like a later printf() or some other library call failing when it calls the real malloc(), and I'd also lose out on features like realloc() being able to move memory around by asking the OS to remap pages rather than copying them.
Indeed, it would probably make a lot of sense if malloc(), like the good OpenGL stacks, simply started swapping to temporary files when it could no longer allocate more memory. Even better if it told the application about this so that it can drop things that aren't really necessary (like cached data), and so that the application can rely on the swapping to keep running as it informs the user about the problem and offers a choice to continue on at a snail's pace or to give up and terminate....but that's not what we have. We just have something that returns NULL with no warning whatsoever and leaves it up to the programmer to figure out some way to do something sensible in an environment in which it's no longer safe to make any library calls (since they may use malloc() internally).
The state of error handling is really rotten all the way to the core. It isn't just individual pieces of software that suck at it. Even people who want to do it right are kind of screwed.
...or, at least, it isn't enough that you'll even notice.
I've been working on a free game for a while. Everything it requires is inside the executable. The download is still just over 1 MB. It's small enough that, when trying to get people to try out the game for me, I have issues with people assuming it must be some sort of trojan simply because of its incredibly small size.
Originally I was distributing it like most software, with an executable accompanied by many other files, but this just created issues of people copying the executable but not the graphics files, or copying things but putting them in the wrong directory (which is quite amazing considering that all anyone had to do was extract the ZIP file and run the executable from where it was extracted to). So I included the files in the executable, which brought it up to 10 MB. Later I made it so that most of the graphics come from the server and are cached locally, so that different servers can have different textures, and so now it's only 1 MB.
Also, until a week ago, it was using a dynamically linked version of GLFW for the Linux version. However, I began hearing reports of people not having GLFW available, so I included the necessary apt-get command on the web page so that people would know how to install it....but even then, I heard from several people (which probably means everyone who used the Linux version, given that the game isn't all that popular) that they still couldn't use it because when they used that command on their 64-bit system, it would install the 64-bit version of the library, but my executable is 32-bit.
I suppose I could have installed a 64-bit system somewhere, but honestly, every time I install Linux I have to go through hell figuring out how to make it stop asking for my password every three minutes, as well as changing numerous other idiotic default settings....and also about 50% of the time the system ends up being unusable anyway and I have to install something else. Thus I've learned not to install new versions of Linux, even if I'm already aware of two bugs in the two and a half year old kernel that the current version of Linux Mint I'm using refuses to upgrade to anything newer. (vm86 mode is broken, and there's a thread locking issue that stalls all threads in an application until you open another terminal and type "for i in 1 2 3 4; do cat/dev/zero >/dev/null & done; sleep 0.1; killall cat")
So instead I just statically linked GLFW as well. I'm sure it added something to the size of the executable, but at present, 25% of the executable is a single PNG image used for the player avatar. While 1 MB may seems small for executables these days, there was a time when our whole computers ran in a single MB. Code simply doesn't require that much memory. When people complain of some software's memory usage, it isn't using all that memory due to a bloated code base, it's using it to store data (or memory leaks). To put it into perspective, the RGB data of a 1920x1080 display requires 6 MB of memory to store -- the entire executable for my game will fit into that multiple times. Thus, the memory saved by dynamically linking is inconsequential.
There are still things that aren't statically linked, like X11 libraries and OpenGL, but I suspect that statically linking those would cause more problems than would be solved. After all, if someone doesn't have X11 or OpenGL libraries, they probably don't have X11 or OpenGL. (I'd also have to find their various licenses to see if I'm even allowed to statically link -- LGPL won't allow you to statically link closed-source applications, despite its reputation of being nearly public domain, and so it is useless for closed-source software.)
As for the topic of this article, I also realize my game desperately needs an instal
The prosecution certainly has as much time as it wants. It can gather evidence indefinitely, gaining as much of a head-start against the defense as it would like, before filing charges. In essence, when the prosecutor files charges, that's saying "OK, I'm ready, let's go."
To allow the defense to have as much time as it would like, but not require the defendant to give up their right to a speedy trial at the same time, would only make sense. It's already impossible for the defense to have as much time to prepare a case as the prosecution has. There's no reason someone should have to give up their right to not sit in jail waiting for a trial indefinitely just because their defense needs a little more time to prepare a response, when the prosecution essentially had all the time in the world....but then, making sense isn't all that common, so who knows...
I doubt nature intended us to overeat to the point that we can no longer catch more meals, or outrun predators.
The video I linked to explains things rather well. Sugar: The Bitter Truth (It's a 90 minute lecture by a Doctor who treats pediatric obesity.)
To sum it up as a non-doctor who doesn't remember all the details: Basically, the fructose half of sugar goes straight to the liver, since only the liver can metabolize fructose. Most of it follows a metabolic pathway that turns it directly into fat. The rest follows a pathway that's a complete trainwreck, producing chemicals which increase cholesterol, raise blood pressure, interfere with the leptin hormone (which tells your brain how much fat your body has), and also tell your body that it should take the glucose it got from the sugar and store it as fat as well, rather than use it for energy. The result is that you may be eating a lot of calories, but your body is simply storing them all as fat (and setting itself up for a lot of medical problems) and so you're still hungry because there's so much fat storage going on that you don't have enough energy left over to do anything.
One important factor to consider is that how much you eat in a single sitting is just your brain's estimate of how much food you need at the moment to maintain your metabolism....and, since foods vary in calorie density, it's often wrong.
It makes up for this the next day. If it consumed more energy then it thought, you'll be less hungry. If it consumed less, you'll be more hungry.
So that this might work for a single meal isn't much of a surprise. I'd expect it to fail for any long-term use, however.
To lose weight, one would do much better to simply stop eating Oreos. See Sugar: The Bitter Truth for more information. After simply cutting sugar from my diet, but otherwise eating as much as I wanted to, I lost 75 pounds over 6 months. The only difficult part is the first two weeks, over which it becomes painfully obvious that sugar is addictive since, no matter how much you eat, you're still hungry until you eat something with sugar in it. Once you break that addiction, however, losing weight isn't hard at all. So just stock up on jalapeno poppers and other tasty sugar-free foods and over-consume them for the first two weeks so that you aren't tempted to consume any sugar. Once the addiction is broken, your brain will start regulating your appetite in response to your leptin levels exactly the way nature intended, and you'll just naturally no longer want to overeat.
Rather than play the three tones, however, I simply attached a relay to my parallel port so that the computer could pick up and then hang up the line.
That actually makes them stop calling as well. I guess they're smart enough to realize they're just wasting their time when they get hung up on every time, but not smart enough to realize they're wasting their time when you've ignored the previous hundred messages they've left on your answering machine.
You can also combine it with a phone that you can configure not to ring until it has Caller ID information (by setting different rings for different callers, and thus getting no ring at first since it doesn't have the Caller ID info yet) and you won't even hear the phone ring when the morons call.
My problem isn't that it's Google, but that it's anything at all. (And I already use DuckDuckGo, BTW.)
Pasting into the browser window isn't a good enough reason to send that data over the internet. If I paste it into the URL bar, then perhaps parse it as a URL. If I paste it into the search bar, then send it as a search query. However, Opera goes so far as to take data pasted anywhere where it otherwise wouldn't do something else, and send it to Google as a search query. I sent them a bug report about this years ago, suggesting that they only do this when it's pasted into the URL bar, but apparently they didn't think that was a very good idea.
I did find a work-around, in that if I delete all search providers from Opera except for "find in page" then it will no longer do this. However, it's still a terrible default to have, regardless of which search provider it sends the data to, particularly considering that it's so easy to do, simply by middle-clicking on something you thought was a link but which actually isn't, or by missing a link by a pixel or two. Like I said, it'd make far more sense if I actually had to paste into the URL bar or the search bar in order to trigger this behavior -- you know, if I had to indicate that I wanted it to do this rather than it just assuming it knows what I want.
Opera never takes my suggestions. Years ago I suggested that there be an "upload progress indicator" just like there's a "download progress indicator" so that web sites didn't have to resort to stupid javascript hacks and plugins in order to provide some feedback to users about the progress of file uploads. However, it seems no one is interested in that. Apparently the world easily figured out that giving no progress about the state of a download is a bad idea, but for uploads... Who needs to know when or even if their uploads will ever complete?
Opera has a similar nasty bug... If you middle-click almost anywhere within the browser window, it likes to take the last bit of text you highlighted with your mouse and send it to Google. It's wonderful when you're simply trying to middle-click a link to open it in a new tab, but you're off by a pixel and so instead Opera sends some secret text you didn't want anyone else to see to Google so that it can store it forever in its database of every search query ever submitted.
You can pray that a 100 ohm, 10% tolerance resistor is right at 100 ohms, and yeah, probably that's about what it'll be. Me, I'll measure the thing and I'll *know* what it is.
Obviously you've never done this. The good ones are sorted out and sold as higher tolerances. Thus, if you did find one that was actually 100 ohms, suspecting holy intervention may be appropriate.
I can hear people now saying "so what if it's complex, people can always write wrapper libraries to create simpler interfaces."...but the problem is that that is exactly what's happened. There are far too many wrapper libraries for audio in Linux and they cause a lot of problems. So one has to ask, why should playing a simple bit of PCM data require hundreds of lines of code?
There's always someone who says "sound has worked just fine for years!"
Obviously it works well for some people. It probably works well for the developers, since they can fix their problems, and it probably for some people who coincidentally have similar hardware...
It seems my copy of Linux Mint has no OSS support whatsoever by default. I was trying to play some NSF files the other day, but my NSF player wouldn't work as there's no "/dev/dsp" for it to access. So I tried to find another. Couldn't find one that worked. Eventually had to just use my Windows laptop to play the files....and while one might say that I'd have no problem if my NSF player used ALSA instead, I have to point out that there are a lot of simple little utilities that prefer OSS simply because the ABI is far simpler to learn and use than ALSA. Indeed, I used OSS from some simple little things I did in assembly language. (ASM is no good for large projects.) It isn't even possible to use ALSA from assembly language as it doesn't have a documented ABI, only a C library API.
Honestly, if they'd just start doing audio mixing in kernel space instead of treating the idea like it's some sort of sin (for fuck's sake, it isn't like Linux is a microkernel), and simply create an API (or better yet an ABI) that doesn't require so much effort to learn that the few people who successfully learn it immediately think "I should create a wrapper for this" while the ones who find it to be too complex simply use one of the many (typically broken) wrappers, Linux audio would be a lot less painful.
They kind of want power handed to them just because they have good ideas, rather than to win it by convincing everyone that their ideas are the best.
Take legalization of marijuana for example. One might start a political party for that goal, put a candidate on the ballot, and lose....or they might work on the difficult task of convincing everyone that marijuana should be legalized, at which point they won't have to start a political party because at least one of the existing parties will adopt the position simply because of its popularity and their desire to be elected.
As such, as soon as these people create a new political party, they've already kind of lost. You don't create change by taking your minority views, putting them on a ballot, and hoping that somehow people vote for them despite them being minority views.
I'll be the first to say that we need to switch to proportional representation and also use some form of Condorcet voting, but I don't believe that it's the two party system that is holding back political progress. Sure, it isn't helping, but eliminating it won't solve the real problem. I think our biggest problem is that people who are smart enough to have good ideas, and smart enough to evolve their ideas when they hear valid criticism, are also smart enough to realize just how annoying it is to listen to people talk about things they hardly know anything about, and so they keep their mouths shut. Thus stupid ideas have an evolutionary advantage.
Slashdot Mirror
If I were to pull the plug on a consumer grade mechanical hdd in the middle of a write, would it not lose data as well?
My only guess is that they're looking at it from the point of view of file system corruption with journaling filesystems, and whether or not stuff committed with sync() is actually safely stored on the drive at that point in time or not. However, the poor way in which the author describes this (assuming it's what he's attempting to describe at all) seriously makes me wonder why I should trust that he knows what the hell he's doing.
Some years ago while discussing design of a journaling filesystem with someone in a newsgroup, we were wondering whether sector writes to a hard disk could be expected to be atomic or not. Once a drive has begun writing to a sector, there's a very tiny amount of time it has to keep power in order to finish the sector, which would seem trivial to store in a capacitor, and with some added circuitry, the momentum in the spindle could supply some power as well. Not to mention that attempting to read a half-written sector is going to cause all sorts of hell for an algorithm that assumes there was a full sector there and so it should be able to error correct it into something meaningful, and might cause it to prematurely declare the sector dead and remap it. So it seemed a bit silly to think that a hard disk wouldn't be able to check its power status between sector writes and simply avoid beginning one which it wasn't going to be able to finish reliably, and this would allow someone to utilize this fact when designing a journaling filesystem since they could at least count on any sector they read to contain valid data even if they couldn't count on whether it was current data or old data. For example, each sector of the journal might have an index number allowing old entries to be distinguished from new ones without worry that the drive died half-way while writing the sector, thus causing it to begin with a recent index number but contain older data at the end. Of course, neither of us knew if this was true of how drives worked or not, but one random person took the time to reply simply "sector writes are atomic" for whatever a random person's word is worth.
Solid state drives have a similar issue in that once they begin rewriting their data structures, if they don't finish, then the data on the drive is going to be rather fucked, particularly since they don't work on sectors like traditional hard drives, but rather, each page of flash holds many sectors, and they're not even in linear order but instead there are wear-leveling algorithms in play. So even when the OS asks the drive to sync(), in the interest of speed, since it will have to combine the sectors written with other sectors and additional wear-leveling data before committing it to flash, it's likely in its interest to lie to the OS and say "OK, it's done" when in fact it's merely committing to writing those sectors before it shuts down even if power is cut immediately. Obviously there are a lot of ways to screw up such a commitment and be unable to deliver upon it, and I assume that's what the author of the article is testing.
...but, hell if I know. It'd be nice to hear from someone who actually knows about these things.
I might have to buy a few for myself too. They'll probably just sit in a box somewhere for quite a long time, but the simple fact is that while fluorescent works just fine for me, I do know that incandescent outputs light of all frequencies and so it is technically superior. So if at some point in the future I require that superiority, I want to have the option of using a simple and inexpensive piece of technology that provides it rather than having to search online for the latest and greatest florescent with the closest-to-incandescent-yet-still-not-ideal light output. They're also great for when you need a little bit of heat in a fairly safe form-factor.
The compact fluorescent bulbs are good, but banning the old bulbs is still stupid.
when was the last time you had a hard fault due to ecc parity error?
I've actually had two occasions which I think were the result of a single-bit error in my RAM. (Not exactly what you asked, but still relevant I think.)
On one occasion I was writing some code and got a compilation error in a file I hadn't even been editing. I opened it up and went to the line of the error and found a single character that was incorrect, and after wondering what the hell had happened, I eventually switched the editor to hex mode and realized that the character differed from the correct character by a single bit. I left it alone for a while, confused as to exactly what the hell had happened, and at first I had suspected a disk error, but it eventually occurred to me that the file was probably being read from cache and so it might well be a memory error. So I did something to use a lot of RAM in order to dump the file from cache, then reloaded it, at which point the error was corrected.
On the other occasion, a Linux system I'd been using for years without any issues spontaneously decided to hose itself, with the filesystem essentially committing suicide. One minute it was working and then everything just kind of started falling apart and a few minutes later it decided to remount the filesystem read-only. After that I shut it down to take a look at the drive in another machine, where I found the filesystem to be damaged beyond repair. I eventually found a recovery tool someone had made which spent hours scanning the drive trying to find indications of where the files may have been and was able to recover about 80% of them, but the remaining 20% were file names which contained data from some other file, or folders which were restored as ordinary files with some random data in them, or sometimes even symbolic links. Granted, this sounds a lot more like a random fuck-up by the filesystem driver than anything else, but it'd been at least a year since I'd installed the particular version of Linux I was using and it'd always worked fine before that, and it didn't seem to be a hardware issue either as the same hardware has continued to work fine for years since then. Thus, I can only conclude that just the right bit happened to get flipped to cause the filesystem driver to lose its mind, e.g. a flipped bit in its instruction code changed it in such a way that it didn't crash, but it no longer properly manipulated the filesystem data structures either. ...and there may well have been other computer problems I've had in the past which were due to memory errors that I just didn't realize at the time. I used to always consider my computer to be a machine which simply never made mistakes in its calculations, and so when something went wrong it was always the software's fault, but I changed my views after trying to install Gentoo on one particular computer and having the install die with a compilation error. While searching the internet for the cause, I found a forum thread about similar errors which suggested that the problem may be the hardware, and as a simple test, suggested simply running the compile again to verify that the error is identical. So I ran it again, and got a completely different error. Then I tried yet again and got a third completely different error. So I took the machine apart and blew the dust out of the CPU heat sink, and after that it worked just fine. Apparently the Gentoo folks have to deal with a lot of bug reports that are the result of hardware errors, since their many compiles are often the hardest and most sustained work that your average PC ever sees.
You probably get more hardware errors than you realize. It's just that, given how software tends to crash now and then, it's far easier to assume it was merely the software's fault that it did whatever it did, rather than to consider that maybe your hardware makes some extremely rare errors.
Being poor, I still have no ECC memory, but I'd love to have some if it weren't so expensive.
Do you actually work for the NSA or do you just have an addiction to cool aid?
I'm actually in disbelief that anyone has taken my suggestions seriously. Someone even modded it "troll." It was just a random idea that popped into my head as I was writing the post which I found too amusing, in a conspiracy theory sort of way, to not mention. It shouldn't be taken any more seriously than that.
They make the all too common mistake of believing that 'literally' is just an emphatic and 'categorically' is a stronger emphatic.
This thought crossed my mind as well. No one bothers to learn what words mean before using them. I make it a point to ask for a definition whenever anyone uses a word I don't know, and amusingly enough they almost always give a definition that even I know isn't correct. I had to look up "categorically" after reading it in their statement, and so, being one of those words, it wouldn't surprise me to learn that the author doesn't actually know what the word means.
They're lying because the truth would be the end of the company
...and that's kind of my point.
I mean, it's like if Alice killed Bob's dog, and everyone on Slashdot suspects her of it, and points to her twitter feed where she's written "I have no idea where Bob's dog is" as evidence, because they think she's being evasive by not saying "I didn't kill Bob's dog" because she probably tossed it in a dumpster last week and so she technically doesn't actually know where it is now. It'd be pointless for her to post truthful statements that sound like denials because no one is going to care that she didn't lie about it if, in the future, a security camera video surfaces of her dumping the body in a dumpster behind Wal-Mart. So why would she risk the suspicion caused by evasive statements when she could instead use direct lies like "I did not kill Bob's dog" and avoid the unnecessary suspicion they create?
This is why I think it's a bit silly to pick apart RSA's statement as if we're going to dig out some hidden meaning. They certainly didn't just mean to imply that they didn't do it without actually telling any lies. They meant what they appear to have said and apparently just didn't anticipate that people might try their best to misunderstand them. People who betray their customers for cash aren't going to be worried about being caught lying to them as well. So either they did it and they're lying about it, or they didn't do it and they're not lying about it. Either way, assuming their statement has some secret meaning other than "we didn't do it" seems ridiculous.
every system that can access plain text can access binary as well.
True, but it should use fewer cycles and fewer amp hours for the ARM system to translate the textual intermediate representation to x86 or ARM instructions than to translate an x86-64 binary to an intermediate representation and then to x86(-32) or ARM instructions.
Binary doesn't necessarily mean instruction code for any particular processor. Is this why people insist on text so much, because they've come to equate the word "binary" with "compiled executable?"
You certainly wouldn't want it to be x86 code anyway, as modern operating systems lack proper security measures to make running untrusted x86 code a good idea. You'd want a pseudo-bytecode which simply indicates operations to perform and you'd translate that into your native machine code, or just run an interpreter on it. The pseudo-bytecode would be designed such that it cannot even represent operations you don't want your untrusted code to perform and so, as long as your programmers aren't completely inept, converting it to native code and running that would be relatively safe.
Also, compiler-enforced memory safety seems like an accident waiting to happen.
How is memory safety enforced in a compiler more of "an accident waiting to happen" than the same enforced in hardware, which is the source of the terms "segfault" and "general protection fault"? Other than that Oracle has had a poorer track record than AMD and Intel, that is.
Well, first of all, have you ever known your CPU to fail to trigger a segmentation fault when a program performs an invalid access? So it's 100% effective then, right?
What we're concerned about is not detected accidents, but undetected ones. Like when someone finds some way to write a statement that performs something which isn't allowed but which the compiler fails to notice due to the unusual syntax of the statement. In binary form there's only so many ways you can describe an operation. In text there are far more due to there generally being no rules about whitespace, variable name length, the number of digits in your numbers, and many other things. So by using plain text you greatly increase the number of opportunities you have to screw up. That's just fine if you're one of those programmers who believes you'll never accidentally code a buffer overflow into your software, but if you're realistic and realize you're only human, then you realize the wise thing to do is to design a system that's as simple as it can be so that you give yourself as few opportunities to fuck it up as you can.
I mean, technically you can drive your car from the back seat just by sticking your ten year old in the driver's seat and telling them when to turn the wheel, and with some luck you may even be able to do this rather well, but it's a scheme that's more likely to result in disaster than simply sitting behind the wheel yourself, and so you just don't do it that way.
so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.
How is this any less true of images, audio, video, or any other content type on the World Wide Web?
It's not, and the fact that one particular browser exploit I remember involved using "width" and "height" tags on images with values prefixed with 64k zeros, I think it demonstrates my point rather well. We've been parsing text since the beginning of computing and it's still something we regularly fuck up all the time. We should avoid doing it whenever we don't have to do it, and when we do have to do it, we should do it on a machine under the control of the person who supplies the text, since if they hack themselves no one gives a shit.
As for audio and video, they of course include some variable length buffers, but it's k
However, what is the point of ignoring something which the average person spends about 10% of their monthly income on?
I only want to ignore it when trying to track the changing value of a currency because its price is particularly likely to change for reasons that have nothing to do with changes in the value of the currency. It certainly has a lot to do with cost of living, however, and so it should be included when trying to calculate that. At least until other energy alternatives are not only more cost effective but also easily utilized by the average consumer instead of oil, or until we all decide that driving everywhere isn't an essential part of life.
If Wikipedia is to be believed, the CPI's purpose is to track inflation, not to track cost of living, and so they'd be correct to exclude it, but then "consumer price index" would seem to be a bit of a misnomer. The article also seems to say that mortgage rates are included, which to me would seem to be an item that wouldn't accurately reflect inflation, particularly if we have the Federal Reserve adjusting interest rates in order to control inflation according to what we measure it to be using the CPI (if that's how they do it) since that creates a feedback loop. I'd guess it suffers from lack of a clear goal, and so everyone wants to include or exclude certain things depending on what they imagine the CPI should represent, and so it's just another government clusterfuck which only manages to be useful simply because the number of people involved ensures that it can't go completely off track before too many people notice.
I can't say I disagree with businesses using a metric which tracks only inflation when performing such calculations either. Imagine the cost of oil just keeps going up, and for some reason our alternatives vaporize and so we have no alternatives to that higher price... It'd be wonderful if our employers could all just pay us more to compensate but that money has to come from somewhere. In reality we'd all either have to work harder to keep doing the same things (as that increase in the cost of oil represents an increase in the work necessary to produce it) or we'd have to adapt to a lifestyle that doesn't require so much oil.
On the other hand, increases in wages to match inflation are to be expected. Your work has a certain value, and you expect to be compensated for that value, but our money slowly declines in value by design. So if your wages don't increase with inflation then you're getting the opposite of a raise, which is a "lower" I guess. A raise that merely matches inflation isn't a raise at all. ...and that may be why companies don't like to give automatic raises according to inflation. If they don't have an official policy of doing so, then they can pass off such raises as an actual increase in pay, and most people, being largely unaware of inflation, will see it as such.
I have a friend who every year has a talk with his boss about what his pay needs to be, and is certain to point out that if it doesn't increase to match inflation then his boss is telling him that he's not worth as much to him this year as he was last year. It seems to work for him, as does his apparent philosophy that one should never stop looking for better employment, as he makes more money than anyone I else I know. I don't know if he spends an hour a day looking for jobs or what, but from what I've seen, over the years that hour a day has earned him more money than all of the hours he spends at work as he's managed to double his pay by constantly finding a new employer to pay him 10% more than the previous one.
Well, we could pick at their wording, but assuming we take their use of the word "categorically" to mean what the word means, it's rather hard to suggest that they intended to say anything other than what their statement says on the surface: it didn't happen.
Obviously they could be lying, but so could Reuters, or maybe Snowden forged the documents, or maybe Reuters simply misunderstood them, or maybe it's just some sort of bullshit NSA internal documentation intended to mislead any spies who happen to steal the information. (...and it did get stolen, which almost seems to kick that last idea into the realm of possibility.)
Hell, now that I think about it, that might also explain Google et. al.'s denial of their involvement with the NSA as well. I mean, if you can't actually spy on everything your enemies do on the internet, you might just settle for convincing them that you can, so that they're afraid to use the internet and are therefore at a disadvantage by not utilizing a valuable tool. It might also cause them to choose methods of communication that you can easily monitor.
Maybe Edward Snowden stole a honeypot. Wouldn't that just be hilarious? Has he revealed anything that's independently verifiable?
In theory, the text can be translated to x86, ARM, or any other 32- or 64-bit architecture, and the translator enforces some memory safety guarantees.
...and in reality, your text is transmitted in binary, as a series of bytes, using an encoding known as ASCII, which means that every system that can access plain text can access binary as well.
Also, compiler-enforced memory safety seems like an accident waiting to happen. ...but then, so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.
The "everything must be a web site" mentality has confused the hell out of me for ages as well.
For some time I assumed it was probably for portability, but while writing a game I'm sure no one cares about I found that portability actually isn't all that difficult. The number of #ifdef involved to make it compile for both Windows and Linux (and FreeBSD, though I haven't compiled for it in about a year) amount to a very minor part of the code, and probably wouldn't have been even that much if I were more of a fan of using other people's libraries. (It does use GLFW, which no doubt is taking care of at least 95% of the portability issues for me.) I suspect even a Mac OS version wouldn't be too difficult though I never could figure out how to produce one from Linux. Granted, I don't have a reliable Linux version available due to LGPL issues, but no one cares about Linux anyway. They could certainly achieve portability between the platforms they care about (anything Windows runs on, and Mac OS) easily enough with a compiled C program, and if they really cared they could also set up a server farm of Linux machines so that they have a copy of each distribution available to compile a Linux version too.
So then why is it I go to YouTube and deal with shitty web video that barely plays correctly if it does at all? I've seen the red and blue channels reversed in video, I've seen 30-second seek times (even seeking backwards), and at times it simply doesn't work at all. The same goes for hulu.com or any online radio web site. Even Facebook could benefit from having a custom application. ...and all of these things would run more efficiently as an application than they do as a web site.
Hell, the new flickr.com is probably the best example. In their desire to have a wall of images in the search results, the javascript spends so much time examining possible arrangements of the images that the computer grinds to a halt. The web site is damn-near unusable, and certainly only "usable" if you're desperate. As far as "I'm bored so I'll look for something interesting on Flickr" goes, it's positively worse than being bored. Granted, they should do the intelligent thing and just go back to the web site they had, but as long as they're insistent on styling their image indexes like that, if they were to do it in a custom application, it could figure out the arrangements it wants in the blink of an eye and so the user experience wouldn't be so miserable.
The craziest thing about it for me is that, given the choice between making a web site and making a proper application, I'd rather make a proper application. Communicating with a server over a TCP connection is a piece of cake, so I don't need a web browser for that, nor do I want to structure everything as an HTTP request anyway. I also don't have to worry about cross-testing in every version of every web browser. Granted, you do then have to cross-test to different operating systems, but at least between Windows and Linux, I've found most of the issues that crop up tend to be data access errors that show up in one version but not the other simply due to data being arranged differently in each executable, and I haven't even seen that since compiling with -fstack-protector-all and writing a wrapper for malloc() in an effort to catch any invalid data access. With web sites I always seem to spend at least 20% of my time trying to make things look at least reasonable in every web browser, and I'm not one of those people who even tries to do fancy shit, I just keep running issues into things like one web browser inserting a blank line somewhere where another doesn't and trying to figure out some way to structure everything so that, if they can't all look the same, then at least none of them end up with ass-ugly formatting.
So I can only guess that the "everything must be a web site" is a user-driven demand.
Part of that might be the Windows convention that no matter how trivial
Bitcoin is fluctuating in value right now precisely because people are betting on its future usefulness as a currency.
Actually, they're merely betting on its future value. This idea that the value of a bitcoin is related to the usefulness of a bitcoin is false. It's merely an effect of supply and demand, to which usefulness is a factor, but hardly the only one, and probably not even the largest one at present.
Are dollars any less useful today than they were a hundred years ago, despite the much lower value they have today? The value of a currency is irrelevant to its usefulness. If it's worth less, then you're simply paid more of it for your work, and you pay more of it for things you want. If it's worth more, then you're simply paid less of it for your work, and you pay less of it for things you want. The value is in work and in property, the currency is just a measure, like meters and feet. You'll note that the length of a meter has nothing to do with it's usefulness of a unit of measure, and it would be useful as a unit of measure no matter what its length, just so long as its length is constant over space and time.
That's kind of what's driving this insane deflation Bitcoin is seeing. People want to invest in it, and so they decide how much they want to invest, say $100, and then they buy $100 worth of bitcoins, however many that is at the moment. It doesn't matter to them how many they get since the value of the currency is simply what they expect to exchange it for in the future, and they expect that to be more than they exchange for it in the present. Indeed, I guarantee you they're all looking at it not as "now I own 0.15 bitcoins" but rather "now I own $100 of bitcoins" -- bitcoins themselves are such a poor measure of value that people measure the number of bitcoins they have in terms of another currency rather than in terms of bitcoins because "0.01 bitcoins" doesn't hold any meaning to anyone because what it means changes far too often to be worth learning.
The same thing is certainly going on with gold. Is that 1 gram of gold really worth $50 to you? If so, it's probably only because you can exchange it for $50, not because you have anything you can do with it that you feel is worth its $50 cost. The same is true of bitcoins, but even worse because bitcoins are ultimately useful for nothing other than exchanging for other value, and people don't end up holding some small piece of metal in their hand wondering "why did I pay $50 for this?" They're told that 0.075 bitcoins are worth $50 and so they're worth $50 to them.
Dollars are really no different in that regard. What makes them different is that their value is regulated by the Federal Reserve. Bitcoin's (and gold's) value will vary depending upon supply and demand. Dollars would do the same thing, but the federal reserve regulates the value by changing the interest rate it charges for loans on money it creates out of thin air (or, actually, cotton). When it wants the value of a dollar to go down, it lowers the interest rate, so people are more easily able to acquire money and so the value goes down. When it wants the value to go up, it raises the interest rate, making money harder to acquire, and also pulling money back out of existence as the previous loans are repaid and not renewed and so that money is destroyed. The result is that supply and demand can be factored out of the currencies value, and it can become useful as a measure of value, since its most important quality in measuring value, like the meter, is that the measurement is stable over time. Bitcoin, of course, has no such mechanism in place, and so the value is always going to fluctuate randomly. It may become more stable over time as it sees more use, but whereas you can predict that dollars will see about a 4% annual inflation rate, and be worth about half what they are now in 20 years, you'll be unable to make any such predictions for bitcoin.
As for that inflation the federal reserve creates, I su
I'm not sure that comparing costs of anything oil-based is really fair. The idea of judging currency based on how much it buys is that you want to choose commodities which have the same value over time, but oil isn't known for being stable. It's not far off from judging inflation by tracking the cost of bitcoins. (well, actually it is -- bitcoins are quite unstable) Cars aren't necessarily fair game either since safety standards change over the years, and given that a higher investment in a car can save you money over the long term in fuel, such technology arriving can cause car prices to increase by consumer demand as they want what that increased cost pays for, meaning that the cost increase isn't an actual cost increase, but instead it's consumers choosing to buy more than what they were buying before.
That's why these things are usually done via average of the cost of many different things, and exclude things known to vary in price a lot.
Anyway, from what little I can remember of the past, I've noticed that common payments for simple fixed-cost utilities (like telephone, cable bill, internet -- things you could do without if you wanted) way back in the late-eighties were all basically $20 a month. Some time between then and now, I noted that they were all $40 a month. Now they all seem to be $60 a month. That's a 25 year time span, and the 25th root of 3 is 1.045, meaning the inflation I've observed in this case has been 4.5% per year. Certainly at the higher end of the 2-4% the GP mentioned, but within the range. Given that such prices aren't actually based on costs at all (they're all provided by monopolies), but rather what sort of value people feel comfortable disposing of for cool things they want, it's hard to say how reliable this is (and let's not forget the accuracy of my memory) but I suspect it's not a terrible measure.
Contrast that with bitcoin which a year ago was valued at $14 or so, and at the present moment is $661, which gives us a *monthly* deflation rate of 38%, which understates the issue by pretending it's a constant change, whereas it's really quite random.
Personally, I like the obsession with menu bars at the top and bottom. It ensures that applications aren't hungry for additional monitor width, which means I can actually run two of them side-by-side on the same monitor. If they start making use of that additional width then I'll no longer be able to do that.
Menus on the left or right also take up far more pixels than menus on the top or bottom simply because text is written left to right. So applications that use menus on the left or right easily eat away the additional width that comes with wide-screen monitors, putting us right back in the situation we were in with 4:3 monitors where most applications (particularly web browsing) are impossible to use without consuming the entire screen.
There is always this desire to make a Swiss Army knife. But you have to make compromises, and those compromises directly impact the capabilities as well as the cost of the robot.
...and the logical conclusion of that is to design the robot to do one specific task and it will do that task very well at minimal cost.
We already have things like that. We call them machines. While these "robot manufacturers" a.k.a. kids with too much money on their hands who want to pretend like they're investing it while they waste it away building cool toys... Anyway, while they like to sit around and imagine their robots that can lift a whole 3 pounds and move it at a mind-boggling 10 cm/s will find thousands of uses, I'd be a lot more impressed if they could give even one real-life example where employing their robots saves a company money and does so in a way where it isn't possible to save much more money simply by hiring workers or using a custom-built machine.
If a custom-built machine can handle those 3 pound objects a thousand times faster, then employing a thousand of those robots to do the same amount of productive work isn't a wise business decision, even if you can still be profitable, as that machine is probably going to cost you far less than $35 million. So using the robots has to not simply be profitable, but has to be at least in the ballpark of how profitable other methods are.
There are two stinky common problems with my game, both of which annoy the hell out of me, but neither of which I can really do anything about.
The first is issues with graphics rendering. It seems that, even though OpenGL has a way to report errors like "out of memory," a lot of graphics drivers simply don't bother to do so. Instead they just render shit incorrectly and generally fuck shit up. The result is that it looks like the game sucks, but the truth is the game isn't being told anything about what's wrong. It presently doesn't pay attention other than to report the errors on stderr, but then to my knowledge, nothing useful has ever come out of OpenGL's error reporting functions, so it isn't like I'm missing out on a chance to give useful information to the user. Indeed, the graphics stacks which don't have these problems seem to deal with low memory not by reporting an error, but by swapping things to system memory where, if memory usage goes up further, the OS begins swapping out to disk. Thus the good drivers just get slower when they run low on memory, but otherwise present no errors. The bad ones just randomly drop textures and display lists, and again present no errors.
The second is issues with malloc(). Sure, malloc() will tell you when it cannot allocate memory. The problem is that there's generally nothing you can do in that case other than to terminate the program. You can't even printf() about the error because printf() uses malloc() internally and so if malloc() isn't working, printf() won't work either. Nevermind trying to do something more reasonable like display a message to the user about what went wrong and what they might be able to do about it.
Unfortunately, many of the tools programmers rely upon to make software have been written lazily, and so even if you yourself write your code to detect as many errors as possible, there are still plenty you can't do anything about. My game checks the return value of everything. In most cases it just prints a message to stdout and exits, as many errors are just so unlikely that it isn't worth the trouble of writing code to do anything else. Even so, I still get malloc() errors that don't make sense. I made it track memory usage and found that malloc() fails after allocating 400 MB of data on systems with 4 GB and no other software running. I have no clue why it's happening, and I can't do anything about it after it happens. It'd be nice if malloc() were more informative about why it is failing than to simply return NULL as a generic error. I've thought about simply doing one huge malloc() for everything I need and then write my own memory allocator to allocate out of that chunk so that I can be guaranteed to get what I need, but even that doesn't solve problems like a later printf() or some other library call failing when it calls the real malloc(), and I'd also lose out on features like realloc() being able to move memory around by asking the OS to remap pages rather than copying them.
Indeed, it would probably make a lot of sense if malloc(), like the good OpenGL stacks, simply started swapping to temporary files when it could no longer allocate more memory. Even better if it told the application about this so that it can drop things that aren't really necessary (like cached data), and so that the application can rely on the swapping to keep running as it informs the user about the problem and offers a choice to continue on at a snail's pace or to give up and terminate. ...but that's not what we have. We just have something that returns NULL with no warning whatsoever and leaves it up to the programmer to figure out some way to do something sensible in an environment in which it's no longer safe to make any library calls (since they may use malloc() internally).
The state of error handling is really rotten all the way to the core. It isn't just individual pieces of software that suck at it. Even people who want to do it right are kind of screwed.
...or, at least, it isn't enough that you'll even notice.
I've been working on a free game for a while. Everything it requires is inside the executable. The download is still just over 1 MB. It's small enough that, when trying to get people to try out the game for me, I have issues with people assuming it must be some sort of trojan simply because of its incredibly small size.
Originally I was distributing it like most software, with an executable accompanied by many other files, but this just created issues of people copying the executable but not the graphics files, or copying things but putting them in the wrong directory (which is quite amazing considering that all anyone had to do was extract the ZIP file and run the executable from where it was extracted to). So I included the files in the executable, which brought it up to 10 MB. Later I made it so that most of the graphics come from the server and are cached locally, so that different servers can have different textures, and so now it's only 1 MB.
Also, until a week ago, it was using a dynamically linked version of GLFW for the Linux version. However, I began hearing reports of people not having GLFW available, so I included the necessary apt-get command on the web page so that people would know how to install it. ...but even then, I heard from several people (which probably means everyone who used the Linux version, given that the game isn't all that popular) that they still couldn't use it because when they used that command on their 64-bit system, it would install the 64-bit version of the library, but my executable is 32-bit.
I suppose I could have installed a 64-bit system somewhere, but honestly, every time I install Linux I have to go through hell figuring out how to make it stop asking for my password every three minutes, as well as changing numerous other idiotic default settings. ...and also about 50% of the time the system ends up being unusable anyway and I have to install something else. Thus I've learned not to install new versions of Linux, even if I'm already aware of two bugs in the two and a half year old kernel that the current version of Linux Mint I'm using refuses to upgrade to anything newer. (vm86 mode is broken, and there's a thread locking issue that stalls all threads in an application until you open another terminal and type "for i in 1 2 3 4; do cat /dev/zero > /dev/null & done; sleep 0.1; killall cat")
So instead I just statically linked GLFW as well. I'm sure it added something to the size of the executable, but at present, 25% of the executable is a single PNG image used for the player avatar. While 1 MB may seems small for executables these days, there was a time when our whole computers ran in a single MB. Code simply doesn't require that much memory. When people complain of some software's memory usage, it isn't using all that memory due to a bloated code base, it's using it to store data (or memory leaks). To put it into perspective, the RGB data of a 1920x1080 display requires 6 MB of memory to store -- the entire executable for my game will fit into that multiple times. Thus, the memory saved by dynamically linking is inconsequential.
There are still things that aren't statically linked, like X11 libraries and OpenGL, but I suspect that statically linking those would cause more problems than would be solved. After all, if someone doesn't have X11 or OpenGL libraries, they probably don't have X11 or OpenGL. (I'd also have to find their various licenses to see if I'm even allowed to statically link -- LGPL won't allow you to statically link closed-source applications, despite its reputation of being nearly public domain, and so it is useless for closed-source software.)
As for the topic of this article, I also realize my game desperately needs an instal
The prosecution certainly has as much time as it wants. It can gather evidence indefinitely, gaining as much of a head-start against the defense as it would like, before filing charges. In essence, when the prosecutor files charges, that's saying "OK, I'm ready, let's go."
To allow the defense to have as much time as it would like, but not require the defendant to give up their right to a speedy trial at the same time, would only make sense. It's already impossible for the defense to have as much time to prepare a case as the prosecution has. There's no reason someone should have to give up their right to not sit in jail waiting for a trial indefinitely just because their defense needs a little more time to prepare a response, when the prosecution essentially had all the time in the world. ...but then, making sense isn't all that common, so who knows...
I doubt nature intended us to overeat to the point that we can no longer catch more meals, or outrun predators.
The video I linked to explains things rather well. Sugar: The Bitter Truth (It's a 90 minute lecture by a Doctor who treats pediatric obesity.)
To sum it up as a non-doctor who doesn't remember all the details: Basically, the fructose half of sugar goes straight to the liver, since only the liver can metabolize fructose. Most of it follows a metabolic pathway that turns it directly into fat. The rest follows a pathway that's a complete trainwreck, producing chemicals which increase cholesterol, raise blood pressure, interfere with the leptin hormone (which tells your brain how much fat your body has), and also tell your body that it should take the glucose it got from the sugar and store it as fat as well, rather than use it for energy. The result is that you may be eating a lot of calories, but your body is simply storing them all as fat (and setting itself up for a lot of medical problems) and so you're still hungry because there's so much fat storage going on that you don't have enough energy left over to do anything.
One important factor to consider is that how much you eat in a single sitting is just your brain's estimate of how much food you need at the moment to maintain your metabolism. ...and, since foods vary in calorie density, it's often wrong.
It makes up for this the next day. If it consumed more energy then it thought, you'll be less hungry. If it consumed less, you'll be more hungry.
So that this might work for a single meal isn't much of a surprise. I'd expect it to fail for any long-term use, however.
To lose weight, one would do much better to simply stop eating Oreos. See Sugar: The Bitter Truth for more information. After simply cutting sugar from my diet, but otherwise eating as much as I wanted to, I lost 75 pounds over 6 months. The only difficult part is the first two weeks, over which it becomes painfully obvious that sugar is addictive since, no matter how much you eat, you're still hungry until you eat something with sugar in it. Once you break that addiction, however, losing weight isn't hard at all. So just stock up on jalapeno poppers and other tasty sugar-free foods and over-consume them for the first two weeks so that you aren't tempted to consume any sugar. Once the addiction is broken, your brain will start regulating your appetite in response to your leptin levels exactly the way nature intended, and you'll just naturally no longer want to overeat.
I once made something similar, by attaching my telephone line to my sound card input and decoding the Caller ID information in software.
http://www.ecstaticlyrics.com/electronics/telephone/CallerID/
Rather than play the three tones, however, I simply attached a relay to my parallel port so that the computer could pick up and then hang up the line.
That actually makes them stop calling as well. I guess they're smart enough to realize they're just wasting their time when they get hung up on every time, but not smart enough to realize they're wasting their time when you've ignored the previous hundred messages they've left on your answering machine.
You can also combine it with a phone that you can configure not to ring until it has Caller ID information (by setting different rings for different callers, and thus getting no ring at first since it doesn't have the Caller ID info yet) and you won't even hear the phone ring when the morons call.
My problem isn't that it's Google, but that it's anything at all. (And I already use DuckDuckGo, BTW.)
Pasting into the browser window isn't a good enough reason to send that data over the internet. If I paste it into the URL bar, then perhaps parse it as a URL. If I paste it into the search bar, then send it as a search query. However, Opera goes so far as to take data pasted anywhere where it otherwise wouldn't do something else, and send it to Google as a search query. I sent them a bug report about this years ago, suggesting that they only do this when it's pasted into the URL bar, but apparently they didn't think that was a very good idea.
I did find a work-around, in that if I delete all search providers from Opera except for "find in page" then it will no longer do this. However, it's still a terrible default to have, regardless of which search provider it sends the data to, particularly considering that it's so easy to do, simply by middle-clicking on something you thought was a link but which actually isn't, or by missing a link by a pixel or two. Like I said, it'd make far more sense if I actually had to paste into the URL bar or the search bar in order to trigger this behavior -- you know, if I had to indicate that I wanted it to do this rather than it just assuming it knows what I want.
Opera never takes my suggestions. Years ago I suggested that there be an "upload progress indicator" just like there's a "download progress indicator" so that web sites didn't have to resort to stupid javascript hacks and plugins in order to provide some feedback to users about the progress of file uploads. However, it seems no one is interested in that. Apparently the world easily figured out that giving no progress about the state of a download is a bad idea, but for uploads... Who needs to know when or even if their uploads will ever complete?
Opera has a similar nasty bug... If you middle-click almost anywhere within the browser window, it likes to take the last bit of text you highlighted with your mouse and send it to Google. It's wonderful when you're simply trying to middle-click a link to open it in a new tab, but you're off by a pixel and so instead Opera sends some secret text you didn't want anyone else to see to Google so that it can store it forever in its database of every search query ever submitted.
You can pray that a 100 ohm, 10% tolerance resistor is right at 100 ohms, and yeah, probably that's about what it'll be. Me, I'll measure the thing and I'll *know* what it is.
Obviously you've never done this. The good ones are sorted out and sold as higher tolerances. Thus, if you did find one that was actually 100 ohms, suspecting holy intervention may be appropriate.
If you don't believe ALSA is just too complicated, look at this "simple" example:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
I can hear people now saying "so what if it's complex, people can always write wrapper libraries to create simpler interfaces." ...but the problem is that that is exactly what's happened. There are far too many wrapper libraries for audio in Linux and they cause a lot of problems. So one has to ask, why should playing a simple bit of PCM data require hundreds of lines of code?
There's always someone who says "sound has worked just fine for years!"
Obviously it works well for some people. It probably works well for the developers, since they can fix their problems, and it probably for some people who coincidentally have similar hardware...
It seems my copy of Linux Mint has no OSS support whatsoever by default. I was trying to play some NSF files the other day, but my NSF player wouldn't work as there's no "/dev/dsp" for it to access. So I tried to find another. Couldn't find one that worked. Eventually had to just use my Windows laptop to play the files. ...and while one might say that I'd have no problem if my NSF player used ALSA instead, I have to point out that there are a lot of simple little utilities that prefer OSS simply because the ABI is far simpler to learn and use than ALSA. Indeed, I used OSS from some simple little things I did in assembly language. (ASM is no good for large projects.) It isn't even possible to use ALSA from assembly language as it doesn't have a documented ABI, only a C library API.
Honestly, if they'd just start doing audio mixing in kernel space instead of treating the idea like it's some sort of sin (for fuck's sake, it isn't like Linux is a microkernel), and simply create an API (or better yet an ABI) that doesn't require so much effort to learn that the few people who successfully learn it immediately think "I should create a wrapper for this" while the ones who find it to be too complex simply use one of the many (typically broken) wrappers, Linux audio would be a lot less painful.
They kind of want power handed to them just because they have good ideas, rather than to win it by convincing everyone that their ideas are the best.
Take legalization of marijuana for example. One might start a political party for that goal, put a candidate on the ballot, and lose. ...or they might work on the difficult task of convincing everyone that marijuana should be legalized, at which point they won't have to start a political party because at least one of the existing parties will adopt the position simply because of its popularity and their desire to be elected.
As such, as soon as these people create a new political party, they've already kind of lost. You don't create change by taking your minority views, putting them on a ballot, and hoping that somehow people vote for them despite them being minority views.
I'll be the first to say that we need to switch to proportional representation and also use some form of Condorcet voting, but I don't believe that it's the two party system that is holding back political progress. Sure, it isn't helping, but eliminating it won't solve the real problem. I think our biggest problem is that people who are smart enough to have good ideas, and smart enough to evolve their ideas when they hear valid criticism, are also smart enough to realize just how annoying it is to listen to people talk about things they hardly know anything about, and so they keep their mouths shut. Thus stupid ideas have an evolutionary advantage.