I am sick and fucking tired of the stupidity of calling it fake raid and refusing to support it. It is not fake, it stripes and mirrors the same as all raid. So it doesn't have all the features and uses some of the cpu resource to run, it is still real raid.
It is fake. There's no RAID on that board. You get no increased performance from it. All you have is a config app in the BIOS. The actual RAID happens in 100% software in the Windows driver for it.
Linux has a software RAID that works just as good, and which will let you assemble the array on another motherboard without any problems.
That is just one example of my frustration. Constantly having to use second rate programs because the the GPL is so restrictive and viral that no software vendor wants to deal with it.
I must be imagining Red Hat, and Novell, and IBM, and Apple (KHTML is LGPL), and a few other companies.
As much as people spout 'open source' it isn't. It places as hard or harder restrictions on its use as any proprietary software, they are just different restrictions. But it definitely is not open.
That's a strange argument. Sure it's open. You can look at it all you want. You can even mess with it all you want. That's open.
Now you can maybe argue that it's not "free" if there are restrictions on it, but that's a different argument.
I know I'll be modded down for this, but I had to say it. There will never be a year of the Linux desktop.
See, not everybody really wants a year of the Linux desktop. Personally I'm pretty happy with things where they are. If a year of the Linux desktop happens, great, if not, I won't consider it to be a huge deal. I use it because I like it, not because that's what other people use.
I don't see KDE or Gnome changing their toolkit just because Google goes and releases something. I also don't see Google expending the effort needed to build a fully featured toolkit as a part of writing a web browser. Do you really think that because Google releases a toolkit people will throw out millions of lines of code and go recode text editors and CD burning apps with it?
Google might have influence, but it doesn't have near enough to impose any sort of standarization. And they're not infallible by any measure, as some of their projects flopped.
For instance, I don't use any google products besides the search engine, and don't really care about what they release. It's again exactly the same problem, Google can release whatever they want, but I'm perfectly fine with my KDE and most likely won't switch even if Google makes something better. It works for me and that's enough. Nobody can force me to switch. Nobody can stop me from contributing to KDE. This is the problem.
Actually, I'm not trying to troll here. Simply stating how things are.
There is no effective power that can force standarization to happen. There's nothing that will make the KDE developers suddenly collectively decide "Ok, we admit it. There needs to be a standard and we're on the wrong side. We'll all go code on Gnome now", or the reverse of that.
The best outcome that there could be is something becoming a defacto standard, by gainining significantly more users than the alternative. But that won't happen in the name of standarization, it'll happen because users like it better.
Ok, I'll agree, Linux needs to be more standarized.
And everywhere in the world the electric grid needs to use the same voltage, frequency and wall sockets. And there should be only one currency on the planet. And...
Problem with all those things is that they're not about to happen. We can talk all day about how Linux has too many audio systems (and I don't disagree), but the thing is that simply talking about it gets nothing done, and there's nobody capable of applying the pressure needed to get it done.
The problem I have with these arguments isn't that they're incorrect. They may be 100% correct, but ultimately all that results is a huge flamewar on slashdot and nothing productive. Some people will argue that there needs to be a standard, some will reply will "You will take my Gnome from my cold, dead hands", some replacing Gnome with KDE.
Then when the dust settles, people go back to their Windows, OS X, KDE and Gnome, developers continue coding for each of those, and nothing changes. And somebody makes yet another sound daemon. And a few months later there's yet another discussion about the same thing with the same results.
There's no "Linux community". There is a lot of communities of different sizes, many of which don't give a damn about each other, plus individual developers doing their own thing.
It's like asking, why does the "programming community" keep inventing new languages? Can't we just all settle on C?
There's a guy somewhere working on some project who got really fed up with say, artsd, and decided that writing a successful sound daemon would look good on his resume. And we end up with yet another sound system. And if you come to him complaining about the lack of unification he'll tell you he's doing it on his own time, has X very happy users and doesn't really care about what you think.
Fast forward a few decades, and to a 0th order approximation, all apps are written for Windows, and Unix derivatives are dead on the desktop.
You're forgetting about OS X here.
The only way Linux can hope to succeed is to present a unified environment to developers *and* users. Period. Yes, that means the over-complex KDE will have to die. Yes, that means binary compatibility must stop being broken from OS update to OS update. Yes, that means supporting DRM so that users can play their streaming videos from Netflix.
Won't happen. Period.
What you're saying is along the lines of "The EU will have to die, and all countries will have to become states of the USA". Nice ideal maybe, except for all those people who want to have nothing to do with the american government. And things will go exactly the same way if phrased as "America will have to die, and all countries will have to become members of the EU".
KDE won't die so long there are people interested in working on it. It doens't matter how many people proclaim that it, or Gnome, or whatever else must go in the name of unification.
Even if what you said is the complete undisputable truth, the fact is that in the absence of any effective pressure nobody really gives a damn about what you or anybody else thinks.
For me truth is not about numbers. Once upon a time only a few people beilived that the Sun was the centre of the solar system. Does that mean that truth is relative?
There are certainly degrees of it. Newton didn't work out the whole truth, and Einstein probably didn't either. What Newton figured out works perfectly for the kinds of things we deal with most of the time. So while there are areas where Newton's laws break down, that doesn't make them completely false either.
Surely it cannot be - there is either a God or there is not.
If you put it that simply, yes, that's correct.
But what is a "god"? Why if there is one it must be the one you believe in? Why can't there be several?
That's the question I'm asking. We've got people searching for the truth around all the world. But if you look at the US, there's maybe 1% of believers in Shinto, and if you go to Japan about 1% believe in Christianity. Yet in both places, people will agree on Netwon's law of motion. Why?
IMO, it's because things like Newton's laws prove themselves. When they work, they're proven useful, and when they fail they're discarded and replaced with something better.
But that doesn't seem to happen with religions. People believe their own thing in the US and in Japan, and if one of those two wasn't working surely somebody would have noticed by now. But it doesn't seem to be happening. Then there are two possible explanations, one that both work, or both don't. Both working seems implausible, since both religions don't acknowledge and conflict with each other. One doesn't have Jesus, and the other doesn't have Amaterasu.
So my best guess is that neither work. People simply believe whatever they want, like they believe many other things with no proof or evidence of their efficacy, and none of it really matters much in the end.
How do you explain that there are seekers of the truth all around the world, and the vast majority of them seem to think that the truth is the predominant religion wherever they are?
How come only 1% of Japan is Christian? Can really 99% of the population of a country be wrong?
It doesn't matter what sizes the writes are, what's important for this case is how many writes per second there are, and you're not giving that number, so I can only guess (the Windows task manager should be able to tell you, btw).
But anyway, that article you posted is completely true. But it's written from a very pessimist perspective, that being that the write limit is easy to reach, so writes must be avoided at all costs. That's a good thing to think of if you're building something for the long term, but most normal hard disks rarely survive more than a few years, and few remain in use for that long either.
As my calculations show, even a 10K erase limit is quite a lot if you spread it over enough sectors.
Intel guarantees their SSDs for 5 years, and modern drives will switch into a special wear reducing mode if you manage to put them under a load that would make them fail too quickly.
Your data is also probably showing the writes the applications make, but not exactly what gets to the disk. There's a write cache, which will eliminate unnecessary writes, and coalesce some of them into one (for instance, writing to a file character by character will NOT result in a disk write per character). And the SSD is free to internally do the same, and take 10 writes to different sectors and put all that data on the same internal block.
Ok, so let's say those 4MB/minute (IO writes/s would be a better measure) are made from 64K requests. So that's 64 requests/minute, or about one a second.
That's not terribly high, so let's double it to 2 requests a second.
1310720000 max block erases, at 2 per second will last 7585 days, or 20 years.
This assuming a MLC drive with 16GB available for reallocation for it. If you use a SLC drive, you probably won't live long enough to see the disk wear out, and even with MLC it's doubtful you're going to keep the same drive around for 20 years. I think that 20 years ago you'd be running a 386 or a 486, and have maybe 200MB of disk space, and can't even plug in a hard disk from back then into most modern computers.
If you're swapping enough to kill a SSD, you're doing it very wrong. Get more RAM, it's cheap.
SSDs do wear levelling, so even if you have a limit of 10K erases that's a per-block limit, and there is a LOT of them on a modern SSD. To kill it, you'll need to make a quite serious effort.
For instance, suppose you leave only 16GB free on your SSD, which has a 128K erase blocks. That means there are 131072 blocks the SSD can recycle, not including whatever amount it reserved internally. To kill those, you'll need to make 1310720000 block erases. That's a pretty big number.
The drive heads are some of the most expensive parts of a hard disk, so it raises the price considerably. Then you get higher power usage, heat generation, decreased reliability, and higher complexity in exchange for the extra performance.
The problem is that normal people don't look at speed, they look at capacity. So they won't buy the expensive drives. And the people who do look at things like bandwidth and latency are already running a RAID and benefitting from multiple heads already. They're also unlikely to want something that's less reliable.
It has a limit, but it's hard to reach even with cheap flash, and almost impossible with good flash unless you're doing something really unusual. And the bigger the disk gets the harder it is to reach it, due to wear levelling.
Also, hard disks are not eternal by any measure, and will fail mechanically, and often without warning and in a much less predictable fashion.
For hard disks, making them much faster isn't really possible. The disk needs to spin faster, or the information needs to be packed more tightly. Currently advances are mostly in the packing, but aren't reaching yet even SATA II levels.
Hard disks will get a slight benefit though because they have a cache and they can transfer data from or to it faster than the platter can handle.
For SSDs, even exceeding SATA 3 is perfectly possible by simply internally parallelizing requests. Also, for SSDs, the interface's latency is probably a fairly significant part of the time it takes to service a request.
If it interferes with normal use, it's a bug. Most users simply _do not care_ about having high quality randomness sources for their keys.
That's a rather shortsighted way of seeing it. Most people also "don't care" about say, the city's garbage disposal, but you can bet they'll start to the moment trash stops getting picked up and stinks the whole street to high heaven.
Using inferior quality randomness isn't really acceptable, because that risks highly unpleasant events, like communications with a bank being compromised and lots of money being transferred out of the account.
The lack of good quality randomness _is_ a longstanding problem. Frankly, I wish tha tthe "Trusted Computing Platform" circuitry and development had been thrown out much sooner, and the circuitry instead invested in a thermal diode to provide truly random encryption keys.
The circuitry has been available for a long time. VIA CPUs have an embedded RNG (as well as very good crypto acceleration). My Tyan board for Athlon MP included a RNG as well.
If you want a RNG, get a server board. Good random number generation can be a bottleneck for SSL, so it's often included.
Every DBA should have had the opportunity to experience the joy of typing "DELETE FROM Customers" and accidently hitting the [Enter] key before the typing in " WHERE Customer ID = 'Bad Customer'".
That's why first of all, you SELECT using the WHERE clause you're planning to use to check that you're choosing the right records.
If it's a very serious matter, or a multiple step operation, then wrap it all in a transaction that's rolled back at the end. Check that the right number of rows have been changed.
Inside that transaction, do a SELECT to verify that the data was changed in the right way.
Only after that, change the ROLLBACK to COMMIT, and re-run.
And then there's the increment functions. MySQL is a bit lacking, with only AUTO_INCREMENT and LAST_INSERT_ID. SQL Server has a similar setup to MySQL using IDENTITY(start, step) and SCOPE_IDENTITY(). But PostgreSQL uses that atrocious monstrosity of SERIAL data types and a damned Sequence object. And heaven help you if the Sequence gets out of sync. Your data is fucked at that point. The DB engine won't fix it. You aren't allowed to fix it. And the next time your app tries to use it, there's a good likelihood that it will lose data.
There's no SERIAL datatype. It's simply a shortcut for creating a sequence, and is equivalent to saying "integer DEFAULT nextval('tablename_colname_seq') NOT NULL".
Also, I'm feeling really curious about this, because:
1. Why would the sequence get out of sync in the first place? 2. If it does, why doesn't using nextval and setval work for fixing it? 3. How will the app lose data? If somehow it generates the same number twice, any attempt to INSERT a row would simply fail.
So please explain how you get what you said to happen.
Debian stable is stable. Once it gets released it doesn't upgrade software to new versions or get new features. It gets bug fixes and security updates and that's it.
If you want a newer version of anything on Debian stable, you have to switch to testing, use a mixed stable/testing system, wait for the next stable release, build it yourself, or use somebody else's packages.
There are distributions like Gentoo which don't follow this model and continously release new versions.
Debian and Ubuntu are not going to upgrade to 5.2. They will take the security fix, backport it to 4.7, and release that as an update. If you check the version you'll get 4.7, even with the fix applied.
Yes, which was too small at the time but as time has moved on Java is faster and all the things you mention even cheap computers have more of.
Yes, of course. Now I have a computer with 4 cores and 8GB RAM. That still doesn't mean that I'm happy to let an application waste RAM, because the amount I have is something that I actually use almost fully.
They were resource constrained for what you were trying to do at the time.
No, they weren't. A box with 256MB RAM, and a 1 GHz P3 would be perfectly capable of downloading files from a 2Mbps connection on the background with no performance impact to the user.
That this task was somehow resource constrained when you did it in Java was the problem.
That is more true of traditional Java applications but does not have to be true. Also of course, JavaFX should be better because it's essentially a scripted app engine that can manage resources better for a desktop app.
That is interesting, mind explain why it won't be true?
As far as I can tell, JavaFX is still Java, runs on top of the same JVM, and should have pretty much the same characteristics.
But there are a large number of small utilities that do not have great options, so people will write new ones - just as they have always done. Why are any new applications written?
The problem is that this is a store built around Java, which is rather strange for PC users. As a PC user I shouldn't care what an application is written in. If I want a text editor, I just want a text editor. What it's written in is largely immaterial so long it works and installs without hassle. It makes no sense to go to a website where I can only find a text editor that's written in Java.
This also means that if by chance there's no desktop program written in Java that does SFTP (haven't checked if there is or isn't), for this store to have one somebody has to write it. And not because what's out there is old or buggy, or because the author thinks he can do better, but because nobody did it in Java yet.
You have tried to use them on resource constrained systems, which does not help - and the apps you were talking about all manage large volumes of data with a lot of simultaneous network connections, a worse case scenario for Java apps.
Those weren't resource constrained systems back then, that's the problem.
At that time, a normal consumer box had 256MB RAM. Maybe 512MB, if they were rather high end. I had a dual Athlon MP with 1GB, but that's because I'm a geek. And even on that box, those applications were slow and large.
And 256/128K ADSL isn't what I'd call a large volume of data, for a computer that would have done perfectly fine on a gigabit network.
I'm not saying Java apps will not generally take a chunk of memory, but I am saying smaller (especially JavaFX apps) will be lighter weight and for most people that don't multi-task as much, not really have that much overhead. Lots of people play Flash games for example and that has more overhead than a Java game would.
Well, maybe. But where's the incentive to use them?
The applications people need already exist, and they're already using them. Remaking every tool in Java seems pointless, and many people will be reluctant to try them due to experiences like with Azureus.
Java applications are remarkably desktop unfriendly because they seem to grow until they reach the maximum amount of memory they can use. While this reduces the amount of GC invocations, it's a pain for the user. If I limit my text editor to 32MB, I won't be able to load a 64MB log file into it. If I give it a top limit of 512MB, chances are it'll eventually grow that large, even with a much smaller file loaded.
And the whole idea of setting the amount of memory an application can use is very user unfriendly as well.
Not if you want to earn money you are not. When I was working in a large company I did not "prefer" to use Outlook. But I did so because I had a job, and Outlook was required.
But that's precisely what I said.
I was replying to your "Incorrect. DEVELOPERS have preferred writing native apps". No, I don't "prefer" writing native apps. I prefer writing in whatever is easier for the task at hand. I have to write in whatever the customer demands, or in whatever is least strange to the user. In my experience, users have a fairly negative reaction towards Java apps, so I wouldn't write one when writing for an user and not my own personal needs.
Normal users don't even know what the hell the JRE is, nor do they care how secure it is at any moment. Give them an installer and care not at all what the app they are about to use is written in.
Actually as an user, I really hate Java apps. I've just never seen a good one. I've also seen very few which probably doesn't help.
Limewire and Azureus are big and slow, even on quite modern hardware. Azureus happily eats 512MB RAM (which is still a very sizable chunk of a modern system). It also uses quite a bit of CPU.
But what really made me hate Java for applications was Freenet. I'm convinced that doing it in Java was a horrible mistake that dramatically limited its userbase. Back when it was new and came up on Slashdot once in a while, Freenet was near impossible to run along with anything else. A box with 128MB RAM could run Apache without any problems, but freenet would bring it to its knees.
The fundamental problem I have is: That somehow the two simple tasks "download files" and "serve files" that could be done on a Pentium 1 with 32MB RAM on the background without the user noticing were turned into huge resource consuming applications.
What happened in the end is that I gave up on freenet, because it'd get my box to OOM every day or so, and got rid of Limewire and Azureus as soon as I managed to find a replacement. Now I use rtorrent and KTorrent.
Resuming: An user may not know what a JRE is, but that's precisely why they don't understand why they have to install one, and Java appears to equal non-standard UI and horrible memory hogging. Not good.
Incorrect. DEVELOPERS have preferred writing native apps. But what if suddenly a lot of useful small utilities appear here, and more and more people start using the app store - people didn't get in on the iPhone app store at first either but when enough people get involved the network effect becomes a powerful force indeed.
Actually no. As a developer I prefer to develop in whatever is easiest for the task at hand. I'll code in Perl on Windows if it's a task Perl is well suited to. But if I coded for other people I wouldn't get a whole lot of users that way.
When I code for other people on Windows, I open Visual Studio, because that produces applications that look native for their system and which install without problems.
What do you mean software based? Video cards didn't have much hardware acceleration back then. Programs typically implemented their own drawing code by writing to 0xA000. About the only "acceleration" I heard of back then was run length encoding, which allowed speeding up GUIs by compressing monochrome chunks (such as black text over white background).
What UniVBE did was providing VESA extensions, which allowed games to get high resolution modes without having a specific driver for the card.
But still, a 386 wasn't very fast (40MHz isn't a whole lot for dealing with 768K pixels), the ISA bus was slow as molasses with 1.2 MB/s (which gives a top speed of 1.6 FPS for updating the whole screen at 1024x768), and unless the program was using a DOS extender, it couldn't comfortably address the whole screen and had to switch segments.
Really there isn't a whole lot a faster video card could have done for a 386.
Slashdot Mirror
It is fake. There's no RAID on that board. You get no increased performance from it. All you have is a config app in the BIOS. The actual RAID happens in 100% software in the Windows driver for it.
Linux has a software RAID that works just as good, and which will let you assemble the array on another motherboard without any problems.
I must be imagining Red Hat, and Novell, and IBM, and Apple (KHTML is LGPL), and a few other companies.
That's a strange argument. Sure it's open. You can look at it all you want. You can even mess with it all you want. That's open.
Now you can maybe argue that it's not "free" if there are restrictions on it, but that's a different argument.
See, not everybody really wants a year of the Linux desktop. Personally I'm pretty happy with things where they are. If a year of the Linux desktop happens, great, if not, I won't consider it to be a huge deal. I use it because I like it, not because that's what other people use.
You're joking, I hope?
I don't see KDE or Gnome changing their toolkit just because Google goes and releases something. I also don't see Google expending the effort needed to build a fully featured toolkit as a part of writing a web browser. Do you really think that because Google releases a toolkit people will throw out millions of lines of code and go recode text editors and CD burning apps with it?
Google might have influence, but it doesn't have near enough to impose any sort of standarization. And they're not infallible by any measure, as some of their projects flopped.
For instance, I don't use any google products besides the search engine, and don't really care about what they release. It's again exactly the same problem, Google can release whatever they want, but I'm perfectly fine with my KDE and most likely won't switch even if Google makes something better. It works for me and that's enough. Nobody can force me to switch. Nobody can stop me from contributing to KDE. This is the problem.
Actually, I'm not trying to troll here. Simply stating how things are.
There is no effective power that can force standarization to happen. There's nothing that will make the KDE developers suddenly collectively decide "Ok, we admit it. There needs to be a standard and we're on the wrong side. We'll all go code on Gnome now", or the reverse of that.
The best outcome that there could be is something becoming a defacto standard, by gainining significantly more users than the alternative. But that won't happen in the name of standarization, it'll happen because users like it better.
Ok, I'll agree, Linux needs to be more standarized.
And everywhere in the world the electric grid needs to use the same voltage, frequency and wall sockets. And there should be only one currency on the planet. And...
Problem with all those things is that they're not about to happen. We can talk all day about how Linux has too many audio systems (and I don't disagree), but the thing is that simply talking about it gets nothing done, and there's nobody capable of applying the pressure needed to get it done.
The problem I have with these arguments isn't that they're incorrect. They may be 100% correct, but ultimately all that results is a huge flamewar on slashdot and nothing productive. Some people will argue that there needs to be a standard, some will reply will "You will take my Gnome from my cold, dead hands", some replacing Gnome with KDE.
Then when the dust settles, people go back to their Windows, OS X, KDE and Gnome, developers continue coding for each of those, and nothing changes. And somebody makes yet another sound daemon. And a few months later there's yet another discussion about the same thing with the same results.
There's no "Linux community". There is a lot of communities of different sizes, many of which don't give a damn about each other, plus individual developers doing their own thing.
It's like asking, why does the "programming community" keep inventing new languages? Can't we just all settle on C?
There's a guy somewhere working on some project who got really fed up with say, artsd, and decided that writing a successful sound daemon would look good on his resume. And we end up with yet another sound system. And if you come to him complaining about the lack of unification he'll tell you he's doing it on his own time, has X very happy users and doesn't really care about what you think.
You're forgetting about OS X here.
Won't happen. Period.
What you're saying is along the lines of "The EU will have to die, and all countries will have to become states of the USA". Nice ideal maybe, except for all those people who want to have nothing to do with the american government. And things will go exactly the same way if phrased as "America will have to die, and all countries will have to become members of the EU".
KDE won't die so long there are people interested in working on it. It doens't matter how many people proclaim that it, or Gnome, or whatever else must go in the name of unification.
Even if what you said is the complete undisputable truth, the fact is that in the absence of any effective pressure nobody really gives a damn about what you or anybody else thinks.
There are certainly degrees of it. Newton didn't work out the whole truth, and Einstein probably didn't either. What Newton figured out works perfectly for the kinds of things we deal with most of the time. So while there are areas where Newton's laws break down, that doesn't make them completely false either.
If you put it that simply, yes, that's correct.
But what is a "god"? Why if there is one it must be the one you believe in? Why can't there be several?
That's the question I'm asking. We've got people searching for the truth around all the world. But if you look at the US, there's maybe 1% of believers in Shinto, and if you go to Japan about 1% believe in Christianity. Yet in both places, people will agree on Netwon's law of motion. Why?
IMO, it's because things like Newton's laws prove themselves. When they work, they're proven useful, and when they fail they're discarded and replaced with something better.
But that doesn't seem to happen with religions. People believe their own thing in the US and in Japan, and if one of those two wasn't working surely somebody would have noticed by now. But it doesn't seem to be happening. Then there are two possible explanations, one that both work, or both don't. Both working seems implausible, since both religions don't acknowledge and conflict with each other. One doesn't have Jesus, and the other doesn't have Amaterasu.
So my best guess is that neither work. People simply believe whatever they want, like they believe many other things with no proof or evidence of their efficacy, and none of it really matters much in the end.
How do you explain that there are seekers of the truth all around the world, and the vast majority of them seem to think that the truth is the predominant religion wherever they are?
How come only 1% of Japan is Christian? Can really 99% of the population of a country be wrong?
It doesn't matter what sizes the writes are, what's important for this case is how many writes per second there are, and you're not giving that number, so I can only guess (the Windows task manager should be able to tell you, btw).
But anyway, that article you posted is completely true. But it's written from a very pessimist perspective, that being that the write limit is easy to reach, so writes must be avoided at all costs. That's a good thing to think of if you're building something for the long term, but most normal hard disks rarely survive more than a few years, and few remain in use for that long either.
As my calculations show, even a 10K erase limit is quite a lot if you spread it over enough sectors.
Intel guarantees their SSDs for 5 years, and modern drives will switch into a special wear reducing mode if you manage to put them under a load that would make them fail too quickly.
Your data is also probably showing the writes the applications make, but not exactly what gets to the disk. There's a write cache, which will eliminate unnecessary writes, and coalesce some of them into one (for instance, writing to a file character by character will NOT result in a disk write per character). And the SSD is free to internally do the same, and take 10 writes to different sectors and put all that data on the same internal block.
Ok, so let's say those 4MB/minute (IO writes/s would be a better measure) are made from 64K requests. So that's 64 requests/minute, or about one a second.
That's not terribly high, so let's double it to 2 requests a second.
1310720000 max block erases, at 2 per second will last 7585 days, or 20 years.
This assuming a MLC drive with 16GB available for reallocation for it. If you use a SLC drive, you probably won't live long enough to see the disk wear out, and even with MLC it's doubtful you're going to keep the same drive around for 20 years. I think that 20 years ago you'd be running a 386 or a 486, and have maybe 200MB of disk space, and can't even plug in a hard disk from back then into most modern computers.
If you're swapping enough to kill a SSD, you're doing it very wrong. Get more RAM, it's cheap.
SSDs do wear levelling, so even if you have a limit of 10K erases that's a per-block limit, and there is a LOT of them on a modern SSD. To kill it, you'll need to make a quite serious effort.
For instance, suppose you leave only 16GB free on your SSD, which has a 128K erase blocks. That means there are 131072 blocks the SSD can recycle, not including whatever amount it reserved internally. To kill those, you'll need to make 1310720000 block erases. That's a pretty big number.
It's been tried, and didn't work well.
The drive heads are some of the most expensive parts of a hard disk, so it raises the price considerably. Then you get higher power usage, heat generation, decreased reliability, and higher complexity in exchange for the extra performance.
The problem is that normal people don't look at speed, they look at capacity. So they won't buy the expensive drives. And the people who do look at things like bandwidth and latency are already running a RAID and benefitting from multiple heads already. They're also unlikely to want something that's less reliable.
It has a limit, but it's hard to reach even with cheap flash, and almost impossible with good flash unless you're doing something really unusual. And the bigger the disk gets the harder it is to reach it, due to wear levelling.
Also, hard disks are not eternal by any measure, and will fail mechanically, and often without warning and in a much less predictable fashion.
For hard disks, making them much faster isn't really possible. The disk needs to spin faster, or the information needs to be packed more tightly. Currently advances are mostly in the packing, but aren't reaching yet even SATA II levels.
Hard disks will get a slight benefit though because they have a cache and they can transfer data from or to it faster than the platter can handle.
For SSDs, even exceeding SATA 3 is perfectly possible by simply internally parallelizing requests. Also, for SSDs, the interface's latency is probably a fairly significant part of the time it takes to service a request.
Saw a grand total of one iPhone in Spain here. The user complained that it sucks.
iPhones are being offered for free with phone plans, and it seems even that isn't helping.
My own phone runs Symbian.
That's a rather shortsighted way of seeing it. Most people also "don't care" about say, the city's garbage disposal, but you can bet they'll start to the moment trash stops getting picked up and stinks the whole street to high heaven.
Using inferior quality randomness isn't really acceptable, because that risks highly unpleasant events, like communications with a bank being compromised and lots of money being transferred out of the account.
The circuitry has been available for a long time. VIA CPUs have an embedded RNG (as well as very good crypto acceleration). My Tyan board for Athlon MP included a RNG as well.
If you want a RNG, get a server board. Good random number generation can be a bottleneck for SSL, so it's often included.
That's why first of all, you SELECT using the WHERE clause you're planning to use to check that you're choosing the right records.
If it's a very serious matter, or a multiple step operation, then wrap it all in a transaction that's rolled back at the end. Check that the right number of rows have been changed.
Inside that transaction, do a SELECT to verify that the data was changed in the right way.
Only after that, change the ROLLBACK to COMMIT, and re-run.
There's no SERIAL datatype. It's simply a shortcut for creating a sequence, and is equivalent to saying "integer DEFAULT nextval('tablename_colname_seq') NOT NULL".
Also, I'm feeling really curious about this, because:
1. Why would the sequence get out of sync in the first place?
2. If it does, why doesn't using nextval and setval work for fixing it?
3. How will the app lose data? If somehow it generates the same number twice, any attempt to INSERT a row would simply fail.
So please explain how you get what you said to happen.
Debian stable is stable. Once it gets released it doesn't upgrade software to new versions or get new features. It gets bug fixes and security updates and that's it.
If you want a newer version of anything on Debian stable, you have to switch to testing, use a mixed stable/testing system, wait for the next stable release, build it yourself, or use somebody else's packages.
There are distributions like Gentoo which don't follow this model and continously release new versions.
That's the wrong way to check it.
Debian and Ubuntu are not going to upgrade to 5.2. They will take the security fix, backport it to 4.7, and release that as an update. If you check the version you'll get 4.7, even with the fix applied.
Yes, of course. Now I have a computer with 4 cores and 8GB RAM. That still doesn't mean that I'm happy to let an application waste RAM, because the amount I have is something that I actually use almost fully.
No, they weren't. A box with 256MB RAM, and a 1 GHz P3 would be perfectly capable of downloading files from a 2Mbps connection on the background with no performance impact to the user.
That this task was somehow resource constrained when you did it in Java was the problem.
That is interesting, mind explain why it won't be true?
As far as I can tell, JavaFX is still Java, runs on top of the same JVM, and should have pretty much the same characteristics.
The problem is that this is a store built around Java, which is rather strange for PC users. As a PC user I shouldn't care what an application is written in. If I want a text editor, I just want a text editor. What it's written in is largely immaterial so long it works and installs without hassle. It makes no sense to go to a website where I can only find a text editor that's written in Java.
This also means that if by chance there's no desktop program written in Java that does SFTP (haven't checked if there is or isn't), for this store to have one somebody has to write it. And not because what's out there is old or buggy, or because the author thinks he can do better, but because nobody did it in Java yet.
Those weren't resource constrained systems back then, that's the problem.
At that time, a normal consumer box had 256MB RAM. Maybe 512MB, if they were rather high end. I had a dual Athlon MP with 1GB, but that's because I'm a geek. And even on that box, those applications were slow and large.
And 256/128K ADSL isn't what I'd call a large volume of data, for a computer that would have done perfectly fine on a gigabit network.
Well, maybe. But where's the incentive to use them?
The applications people need already exist, and they're already using them. Remaking every tool in Java seems pointless, and many people will be reluctant to try them due to experiences like with Azureus.
Java applications are remarkably desktop unfriendly because they seem to grow until they reach the maximum amount of memory they can use. While this reduces the amount of GC invocations, it's a pain for the user. If I limit my text editor to 32MB, I won't be able to load a 64MB log file into it. If I give it a top limit of 512MB, chances are it'll eventually grow that large, even with a much smaller file loaded.
And the whole idea of setting the amount of memory an application can use is very user unfriendly as well.
But that's precisely what I said.
I was replying to your "Incorrect. DEVELOPERS have preferred writing native apps". No, I don't "prefer" writing native apps. I prefer writing in whatever is easier for the task at hand. I have to write in whatever the customer demands, or in whatever is least strange to the user. In my experience, users have a fairly negative reaction towards Java apps, so I wouldn't write one when writing for an user and not my own personal needs.
Actually as an user, I really hate Java apps. I've just never seen a good one. I've also seen very few which probably doesn't help.
Limewire and Azureus are big and slow, even on quite modern hardware. Azureus happily eats 512MB RAM (which is still a very sizable chunk of a modern system). It also uses quite a bit of CPU.
But what really made me hate Java for applications was Freenet. I'm convinced that doing it in Java was a horrible mistake that dramatically limited its userbase. Back when it was new and came up on Slashdot once in a while, Freenet was near impossible to run along with anything else. A box with 128MB RAM could run Apache without any problems, but freenet would bring it to its knees.
The fundamental problem I have is: That somehow the two simple tasks "download files" and "serve files" that could be done on a Pentium 1 with 32MB RAM on the background without the user noticing were turned into huge resource consuming applications.
What happened in the end is that I gave up on freenet, because it'd get my box to OOM every day or so, and got rid of Limewire and Azureus as soon as I managed to find a replacement. Now I use rtorrent and KTorrent.
Resuming: An user may not know what a JRE is, but that's precisely why they don't understand why they have to install one, and Java appears to equal non-standard UI and horrible memory hogging. Not good.
Actually no. As a developer I prefer to develop in whatever is easiest for the task at hand. I'll code in Perl on Windows if it's a task Perl is well suited to. But if I coded for other people I wouldn't get a whole lot of users that way.
When I code for other people on Windows, I open Visual Studio, because that produces applications that look native for their system and which install without problems.
Have you even tried it? It's not a search engine.
Many results it produces are immutable
Data like the population of cities will of course vary over time, but there's quite a lot of stuff in there that's set in stone.
What do you mean software based? Video cards didn't have much hardware acceleration back then. Programs typically implemented their own drawing code by writing to 0xA000. About the only "acceleration" I heard of back then was run length encoding, which allowed speeding up GUIs by compressing monochrome chunks (such as black text over white background).
What UniVBE did was providing VESA extensions, which allowed games to get high resolution modes without having a specific driver for the card.
But still, a 386 wasn't very fast (40MHz isn't a whole lot for dealing with 768K pixels), the ISA bus was slow as molasses with 1.2 MB/s (which gives a top speed of 1.6 FPS for updating the whole screen at 1024x768), and unless the program was using a DOS extender, it couldn't comfortably address the whole screen and had to switch segments.
Really there isn't a whole lot a faster video card could have done for a 386.