You can run whatever you want on Chrome OS, it's just a Linux with Chrome and some extra stuff to allow management through the browser. It wouldn't really be "Chrome" OS anymore, but whatever floats your boat.
I guess it depends on where you consider the "end" to be.
If it's at the user's computer, and all software inside is considered to be trusted, having one of these proxies to scan for malware on the "end computer" could actually improve security. Or if it's at the user's company, then being able to scan all traffic incoming/outgoing might increase (the company's) security. On the other hand, if you consider the "end" to actually be a person, with software in the computer not being 100% trusted, then you're right, this could only reduce the amount of security.
Personally, I'm not that sure about any of these two to be right. Maybe a better way would be to have some traffic proxy-able, some marked as "don't proxy", and running your browser/tabs in a VM... but there might be several different scenarios with different requirements.
You forgot about leaving a MMO like WoW after having done all there was you found fun to do during the las several years, and just not willing to do it all over and over again with the rest of your toons. So you stop playing until the next expansion that will change some of the gameplay and add new stuff.
No need to blame cheating/hacking. Even with the best MMOs you can simply have enough of them.
In EVE you can't sell in-game assets in exchange for out-game ones. Wealth only flows inwards, never outwards. Even if you have assets in EVE that only you can manage, it's at most a delayed way of wealth destruction, initiated the moment you purchase non-refundable in-game assets with out-game money.
That this "destruction pending" wealth can be transferred in-game, accumulated and operated on much like any other wealth, leads to some spectacular chain reactions like this battle, but doesn't affect the economy in any way. Playing the game has already affected the economy long before that.
Fun thing about JavaScript, it's possibly the single language that got most optimized as of late. From a sluggish thing at the dawn of the century, to a snappy language for developing web apps, and an even snappier node.js on the server side.
How about spending 20x the man hours for a 10,000% performance gain? That is what I've recently experienced myself, in the reverse: an embedded device interface getting rewritten to require 20x less man hours to mantain... at a 100x performance hit. Suffice to say it went from quite snappy, to completely useless, but it seems like it's my fault for not upgrading the hardware.
Yes, reducing energy consumption, heat dissipation, hardware lifetime, and being able to swiftly react to sudden spikes of activity, would be excellent.
The sad part is not that it's easier to code, but that many people have grown complacent with their code executing at abysmal performance rates. And I also blame compilers/interpreters that don't mind bloating things up.
So true. I also happen to believe that adding an FPGA coprocessor to general purpose CPUs, that applications could reconfigure on the fly to perform certain tasks, could lead to massive increases in performance.
Human bodies need a constant supply of vitamins and minerals, "stop eating" just doesn't cut it. And you DO NOT know how hard it is, to eat just a bit while constantly craving to eat a lot more, 24/7... unless you've been a drug addict, then you may know it. Otherwise STFU.
Unfortunately it doesn't work like that. You'd think severely obese people don't need to eat at all; try that, and you'll end up with lots of dead people.
The human body can't live just on pure calories, there is a constant need for vitamins, minerals and such, without which it just starts dying. Stored fat has none of those, while at the same time using them up in order to get converted into usable calories. Meanwhile, food sources of this stuff are themselves laced with sugar and additional fats, so doing a minimum calorie while at the same time life sustaining diet, means the actual weight loss will be pretty slow.
Elective surgery doesn't mean you can wait 20 years to get it done... which, depending on your overweight, is what you may need to get your weight down.
Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).
Actually, something broke in my "Modern UI" apps while upgrading to Windows 8.1, and I didn't even bother looking to fix it. Still using Windows as usual.
In Windows XP, display drivers run in kernel mode. Any failure, means a system-wide crash at best, or a hang up at worst. There is no way to schedule/preempt driver execution before it finishes.
Since Windows Vista, display drivers get split up, with a minimal piece running in kernel mode, and most of the driver running in user mode. Most failures just need a restart of the user mode part. The user mode part can be scheduled/preempted at any time, kernel mode part only blocks for a single DMA buffer.
Since Windows 8, display drivers can be preempted up to a single instruction level.
Saying that Windows XP is "very much inferior", seems to me like quite a polite way to put it.
Best naming scheme is Write_processMemory_r1_998 and CreateRemote_thread_rev001_2. No more ambiguity about which part is static and which not.
Bonus: also no need for some silly source control, just change the rev number (or r for release, unless the minor is > 900, which means it's beta), and bam! all the code at your fingertips, all the time!
Meaning: - Some of the extra stuff, you may or may not care about. YMMV - Gadgets supporting Android, get an Android adapted to them by whoever makes them. When your gadget's maker stops giving you updates for whatever reason (like: laziness, or not caring anymore), you can use CyanogenMod to get the latest version of Android with all the patches, updates... and the extra stuff you may or may not care about.
Anything can be rewritten (backported), as long as it works in a turing-complete language. What you would be missing most probably are the optimizations and tuning, which would make your forked 386-compatible kernel slower and slower as more changes are added with the "new stuff".
For example: some of the config options dropped are CMPXCHG, XADD and BSWAP emulation. This means new patches can use these instructions indiscriminately with no performance impact on 386... since it is no longer supported. Yet if you were to backport, it might well turn out that emulating tons and tons of these instructions would make the kernel nearly unusable.
This remids me of the time when I first tried running a Windows 3.0 demo on a 8086 PC. It was intended for 80286, where it ran smoothly... and yet it DID run on my 8086. Only 100,000 times slower (no kidding, over 2 hours just to show the logo splash).
Bitcoins can be subdivided to 8 decimal places, or currently about 1/100,000th of a cent in US dollars. Any deflation that occurs can be handled well into the future.
I see, so you seem to assume logical, rational an mathematically sound beings handling the bitcoins.
Now, how does that hold against a bunch of brainless morons who would rather die of starvation today, than spend a single bitcoin which could earn them more food the next month?
Those that got bitcoins a long time ago have a vested interest in getting others to buy bitcoins.
So, you mean like gold?
Yet when I say that "there are people with a vested interest in getting others to buy gold", people look at me like I'm crazy... even though they never dug up any gold themselves.
I've been using BTRFS in production since 3.3.1 with zero problems.
Before that, I did experience a partial fs meltdown on 3.2.x while stress testing a high number of snapshots with several million files/dirs and intense db activity. Then, the same test on 3.3.1 went flawlessly.
So I wouldn't recommend using BTRFS with anything below 3.3.1, but 3.4 or 3.5 should be fine.
Also we're approaching a population of 10 billion.
In the Middle Ages, 30% of European population died to the plague. Yet by 1800 there were about 1 billion people, and it was enough.
So what if 9 billion would die some day. The remaining 1 billion will still be enough.
And now we do have some technology and knowledge that won't be lost just like that. Think of all the people without jobs, or with menial jobs, or with jobs depending on supporting the aforementioned. Now replace them with robots.
I even wonder if "quality of life" wouldn't rather RISE if 90% of the population died. For the remaining 10% that is... but, oh well, you can't have it all, can you?
Slashdot Mirror
You can run whatever you want on Chrome OS, it's just a Linux with Chrome and some extra stuff to allow management through the browser. It wouldn't really be "Chrome" OS anymore, but whatever floats your boat.
I guess it depends on where you consider the "end" to be.
If it's at the user's computer, and all software inside is considered to be trusted, having one of these proxies to scan for malware on the "end computer" could actually improve security.
Or if it's at the user's company, then being able to scan all traffic incoming/outgoing might increase (the company's) security.
On the other hand, if you consider the "end" to actually be a person, with software in the computer not being 100% trusted, then you're right, this could only reduce the amount of security.
Personally, I'm not that sure about any of these two to be right. Maybe a better way would be to have some traffic proxy-able, some marked as "don't proxy", and running your browser/tabs in a VM... but there might be several different scenarios with different requirements.
Any code can have backdoors. Any open-source code can be checked in the same way for backdoors. So what's the difference?
If they were to spend all that focus, concentration and planning on... like starting WWIII, I'd say better do it in a game ;)
You forgot about leaving a MMO like WoW after having done all there was you found fun to do during the las several years, and just not willing to do it all over and over again with the rest of your toons. So you stop playing until the next expansion that will change some of the gameplay and add new stuff.
No need to blame cheating/hacking. Even with the best MMOs you can simply have enough of them.
It's been some time since I played EVE, but why would you keep PLEX on a ship, instead of on a station or just cash them in right away?
In EVE you can't sell in-game assets in exchange for out-game ones. Wealth only flows inwards, never outwards. Even if you have assets in EVE that only you can manage, it's at most a delayed way of wealth destruction, initiated the moment you purchase non-refundable in-game assets with out-game money.
That this "destruction pending" wealth can be transferred in-game, accumulated and operated on much like any other wealth, leads to some spectacular chain reactions like this battle, but doesn't affect the economy in any way. Playing the game has already affected the economy long before that.
Fun thing about JavaScript, it's possibly the single language that got most optimized as of late. From a sluggish thing at the dawn of the century, to a snappy language for developing web apps, and an even snappier node.js on the server side.
How about spending 20x the man hours for a 10,000% performance gain? That is what I've recently experienced myself, in the reverse: an embedded device interface getting rewritten to require 20x less man hours to mantain... at a 100x performance hit. Suffice to say it went from quite snappy, to completely useless, but it seems like it's my fault for not upgrading the hardware.
Yes, reducing energy consumption, heat dissipation, hardware lifetime, and being able to swiftly react to sudden spikes of activity, would be excellent.
The sad part is not that it's easier to code, but that many people have grown complacent with their code executing at abysmal performance rates. And I also blame compilers/interpreters that don't mind bloating things up.
So true. I also happen to believe that adding an FPGA coprocessor to general purpose CPUs, that applications could reconfigure on the fly to perform certain tasks, could lead to massive increases in performance.
Stop eating... and die already, amiright?
Human bodies need a constant supply of vitamins and minerals, "stop eating" just doesn't cut it. And you DO NOT know how hard it is, to eat just a bit while constantly craving to eat a lot more, 24/7... unless you've been a drug addict, then you may know it. Otherwise STFU.
The more fat they have the less they need to eat.
Unfortunately it doesn't work like that. You'd think severely obese people don't need to eat at all; try that, and you'll end up with lots of dead people.
The human body can't live just on pure calories, there is a constant need for vitamins, minerals and such, without which it just starts dying. Stored fat has none of those, while at the same time using them up in order to get converted into usable calories. Meanwhile, food sources of this stuff are themselves laced with sugar and additional fats, so doing a minimum calorie while at the same time life sustaining diet, means the actual weight loss will be pretty slow.
So, just because you were lazy and didn't "try harder" earlier, you assume everyone is just as lazy, and just needs to "try harder".
Well, guess what, not everybody is like you.
Elective surgery doesn't mean you can wait 20 years to get it done... which, depending on your overweight, is what you may need to get your weight down.
Oh, stop the BS already. You don't have to use Metro if you don't want to (I don't).
Actually, something broke in my "Modern UI" apps while upgrading to Windows 8.1, and I didn't even bother looking to fix it. Still using Windows as usual.
In Windows XP, display drivers run in kernel mode. Any failure, means a system-wide crash at best, or a hang up at worst. There is no way to schedule/preempt driver execution before it finishes.
Since Windows Vista, display drivers get split up, with a minimal piece running in kernel mode, and most of the driver running in user mode. Most failures just need a restart of the user mode part. The user mode part can be scheduled/preempted at any time, kernel mode part only blocks for a single DMA buffer.
Since Windows 8, display drivers can be preempted up to a single instruction level.
Saying that Windows XP is "very much inferior", seems to me like quite a polite way to put it.
Best naming scheme is Write_processMemory_r1_998 and CreateRemote_thread_rev001_2.
No more ambiguity about which part is static and which not.
Bonus: also no need for some silly source control, just change the rev number (or r for release, unless the minor is > 900, which means it's beta), and bam! all the code at your fingertips, all the time!
Has more stuff, works on more devices.
Meaning:
- Some of the extra stuff, you may or may not care about. YMMV
- Gadgets supporting Android, get an Android adapted to them by whoever makes them. When your gadget's maker stops giving you updates for whatever reason (like: laziness, or not caring anymore), you can use CyanogenMod to get the latest version of Android with all the patches, updates... and the extra stuff you may or may not care about.
Anything can be rewritten (backported), as long as it works in a turing-complete language. What you would be missing most probably are the optimizations and tuning, which would make your forked 386-compatible kernel slower and slower as more changes are added with the "new stuff".
For example: some of the config options dropped are CMPXCHG, XADD and BSWAP emulation. This means new patches can use these instructions indiscriminately with no performance impact on 386... since it is no longer supported. Yet if you were to backport, it might well turn out that emulating tons and tons of these instructions would make the kernel nearly unusable.
This remids me of the time when I first tried running a Windows 3.0 demo on a 8086 PC. It was intended for 80286, where it ran smoothly... and yet it DID run on my 8086. Only 100,000 times slower (no kidding, over 2 hours just to show the logo splash).
Bitcoins can be subdivided to 8 decimal places, or currently about 1/100,000th of a cent in US dollars. Any deflation that occurs can be handled well into the future.
I see, so you seem to assume logical, rational an mathematically sound beings handling the bitcoins.
Now, how does that hold against a bunch of brainless morons who would rather die of starvation today, than spend a single bitcoin which could earn them more food the next month?
Those that got bitcoins a long time ago have a vested interest in getting others to buy bitcoins.
So, you mean like gold?
Yet when I say that "there are people with a vested interest in getting others to buy gold", people look at me like I'm crazy... even though they never dug up any gold themselves.
I've been using BTRFS in production since 3.3.1 with zero problems.
Before that, I did experience a partial fs meltdown on 3.2.x while stress testing a high number of snapshots with several million files/dirs and intense db activity. Then, the same test on 3.3.1 went flawlessly.
So I wouldn't recommend using BTRFS with anything below 3.3.1, but 3.4 or 3.5 should be fine.
Also we're approaching a population of 10 billion.
In the Middle Ages, 30% of European population died to the plague. Yet by 1800 there were about 1 billion people, and it was enough.
So what if 9 billion would die some day. The remaining 1 billion will still be enough.
And now we do have some technology and knowledge that won't be lost just like that. Think of all the people without jobs, or with menial jobs, or with jobs depending on supporting the aforementioned. Now replace them with robots.
I even wonder if "quality of life" wouldn't rather RISE if 90% of the population died. For the remaining 10% that is... but, oh well, you can't have it all, can you?