So will the os fragment the string, when it comes up to an other systems reserved memory spot. Will it overwrite it (Buffer overflow), will it find a contiguous larger memory block and copy the data there
Wow, this may have been the case eons ago when MMU's didn't exist, but in a modern day OS, you get an address space that's all your own. Nobody else is using it, and real memory is simply mapped (usually in chunks of 4k or 8k) into your address space -- it can be fragmented all over the place, it will still look like one nice big chunk to your program.
OS Disk management: A lot of the same concerns that memory management has. However a bunch of small request is easier to find free space, then asking for a larger spot. So they may be more seek time
Most filesystems already work with a minimum of 4k chunks. I cast serious doubts on your claim that smaller chunks are easier to find, it would depend on the data structure used for tracking free space and whether the filesystem is reserving space for you by leaving gaps at your last write location.
The program language has to be suited for such tools. The better you can reason about a language the better these tools can be, and Java really nailed that one. That's why you can refactor large code bases with it and have some level of confidence that you didn't break something.
Yes, and it re-rerenders all the pages as bitmaps at 400% zoom, scales them back down to get proper anti-aliased results, then compresses them with JPEG and stores them into main memory......or how about just recalculating the page that you need to display?
Actually, it is a productivity killer which looks like a cost-reduction, but if productivity could be measured in an objective way, it would be unmasked as a net cost increase.
...and I suppose this silent corruption was verified by reading it into main memory?
My own simple tests (copy 1 TB of data from one place to another) on ECC and non-ECC systems showed quite clearly where the culprit was. Bit error rates of 1 bit/100 GB with the non-ECC system showed the problem clearly.
Public transportation takes about 50-100% longer to get where you want, unless you are part of the "lucky" few that live next to a major station and works next to another major station. It also often costs about as much as it would cost in fuel costs -- yes, you can factor in the car costs, but those are sunk costs as living without a car is not an option anyway (I'm not gonna bring my shopping in the train for starters).
Public transportation is really an abysmal failure, especially on the cost aspect. Its supposed to achieve economy of scale, but in reality it can't even beat a car with two passengers (and often not even with one passenger). And that's ignoring the time aspect (time is money, especially my free time).
If you really want to solve these kinds of problems, I'd look beyond transportation, but more to the reason we transport ourselves: work. Make it so people can work from home or nearby reuseable offices.
Java has had quick edit/reload cycles since there was hot code replacement. If you see Java developers recompiling / restarting their entire project every time they make a change, then unfortunately they just don't care enough and/or are incompetent.
For projects that I'm assigned to, the first thing I look at is making sure the turnover time is below 10 seconds.. if it isn't, I fiddle with it until it is. And yes, that works for Facebook sized websites as well.
They invented a square wheel to go with their already mediocre Volkswagen. Meanwhile, languages designed statically to begin with are looking at more important issues that crop up half a dozen iterations further down the road.
Every little bump one of these cars hits already is making me think they're flashing their high beams because the angle of the light that should be pointed at the road is now pointing in my eyes.
Well, perhaps why are we still using text-only to code?
We're not.
However, we're also not burdening the compiler with all this crap anymore -- it is expected you load such resources on demand instead of including it with your code in order to keep the memory footprint reasonable (just imagine the intro movie of some big game being part of its base code).
It wasn't always that way. Assemblers would often have directives to directly include a file as binary as part of the code. C did away with that (although converters for binary files to something a C compiler can understand exist). More new fangled language like for example Java allow you to just include the resources in a zip file (jar file) and load them on demand with a very simple construct.
Kamikaze drones will win the next major air engagement, as they're cheap and there's no human cost involved if you lose one. I don't understand why countries even bother with the F-35 or anything similar. Build an expendable drone that can outfly anything with a human pilot in it -- can even make it stealth if you really want to bother with it.
Slashdot Mirror
Wow, this may have been the case eons ago when MMU's didn't exist, but in a modern day OS, you get an address space that's all your own. Nobody else is using it, and real memory is simply mapped (usually in chunks of 4k or 8k) into your address space -- it can be fragmented all over the place, it will still look like one nice big chunk to your program.
Most filesystems already work with a minimum of 4k chunks. I cast serious doubts on your claim that smaller chunks are easier to find, it would depend on the data structure used for tracking free space and whether the filesystem is reserving space for you by leaving gaps at your last write location.
No, they don't.
The program language has to be suited for such tools. The better you can reason about a language the better these tools can be, and Java really nailed that one. That's why you can refactor large code bases with it and have some level of confidence that you didn't break something.
...or the GIT integration... which is miles ahead of what IDEA offers.
You read the boilerplate? Damn...
It looks like a logarithmic or ranked scale as well, as some obscure stuff is way too high compared to the top contenders.
Safety and performance. Since I got performance, no need to have concurrency.
They paid for that anyway. So, the stupid ones really are the local stations.
Yes, and it re-rerenders all the pages as bitmaps at 400% zoom, scales them back down to get proper anti-aliased results, then compresses them with JPEG and stores them into main memory... ...or how about just recalculating the page that you need to display?
Parallel processing is not gonna solve stupidity.
If nothing has top priority, I take that as: pick whatever you think is best. If it turns out I picked wrong, too bad, set priorities then.
Actually, it is a productivity killer which looks like a cost-reduction, but if productivity could be measured in an objective way, it would be unmasked as a net cost increase.
Yep, it's exactly my setup... 10m HDMI cables (for both monitors), and games work perfectly without any tearing.
That wouldn't have fooled me even then.
Good. We're at the "it's a mental illness" stage. Can't wait to find out which policitical conviction will be classified as such in the 1984 future.
I'd call cropping the image a trivial tweak. How you dealing with that?
...and I suppose this silent corruption was verified by reading it into main memory?
My own simple tests (copy 1 TB of data from one place to another) on ECC and non-ECC systems showed quite clearly where the culprit was. Bit error rates of 1 bit/100 GB with the non-ECC system showed the problem clearly.
Just use ECC RAM. The price difference is tiny.
Of course you can verify, but very few people do that, and it certainly is not something most filesystems do for performance reasons.
You can ask the same for normal cars, as they're basically driving computers these days.
Public transportation takes about 50-100% longer to get where you want, unless you are part of the "lucky" few that live next to a major station and works next to another major station. It also often costs about as much as it would cost in fuel costs -- yes, you can factor in the car costs, but those are sunk costs as living without a car is not an option anyway (I'm not gonna bring my shopping in the train for starters).
Public transportation is really an abysmal failure, especially on the cost aspect. Its supposed to achieve economy of scale, but in reality it can't even beat a car with two passengers (and often not even with one passenger). And that's ignoring the time aspect (time is money, especially my free time).
If you really want to solve these kinds of problems, I'd look beyond transportation, but more to the reason we transport ourselves: work. Make it so people can work from home or nearby reuseable offices.
I just did the same, but instead it involved a 1 TB USB3 drive, which fits in my pant pocket... and it wasn't just one season.
Java has had quick edit/reload cycles since there was hot code replacement. If you see Java developers recompiling / restarting their entire project every time they make a change, then unfortunately they just don't care enough and/or are incompetent.
For projects that I'm assigned to, the first thing I look at is making sure the turnover time is below 10 seconds.. if it isn't, I fiddle with it until it is. And yes, that works for Facebook sized websites as well.
They invented a square wheel to go with their already mediocre Volkswagen. Meanwhile, languages designed statically to begin with are looking at more important issues that crop up half a dozen iterations further down the road.
...only to be defeated by a hill in the road.
Every little bump one of these cars hits already is making me think they're flashing their high beams because the angle of the light that should be pointed at the road is now pointing in my eyes.
Making it even brighter? W...T...F...
We're not.
However, we're also not burdening the compiler with all this crap anymore -- it is expected you load such resources on demand instead of including it with your code in order to keep the memory footprint reasonable (just imagine the intro movie of some big game being part of its base code).
It wasn't always that way. Assemblers would often have directives to directly include a file as binary as part of the code. C did away with that (although converters for binary files to something a C compiler can understand exist). More new fangled language like for example Java allow you to just include the resources in a zip file (jar file) and load them on demand with a very simple construct.
Maybe that was the case a few years ago. Now it is just the phone that only comes in size 6. Don't have size 6? Too bad.
Apple is "special" alright, just not in the way you think.
And this will make a return.
Kamikaze drones will win the next major air engagement, as they're cheap and there's no human cost involved if you lose one. I don't understand why countries even bother with the F-35 or anything similar. Build an expendable drone that can outfly anything with a human pilot in it -- can even make it stealth if you really want to bother with it.
Slashdot works with Javascript disabled.
Your turn.