Well, except that it isn't a mere month. Unpowered data retention is around 10 years for relatively unworn flash and around 1 year for worn flash. Powered data retention is almost indefinite (doesn't matter if the data is static or not). The modern SSD controller will rewrite blocks as the bits leave the sweet zone.
The main benefit, though, is that SSD wear is essentially based on how much data you've written, which is a very controllable parameter and means, among other things, that even a SSD which has been sitting on a shelf for a long time and lost its data can still be used for fresh data (TRIM wipe + newfs). I have tons of SSDs sitting on a shelf ready to be reused when I need them next. I can't really do that with HDDs and still expect them to be reliable.
Hard drives have a relatively fixed life whether powered or not. If you have a modestly used hard drive and take it out and put it on a shelf for a year, chances are it either won't be able to spin up after that year or it will die relatively quickly (within a few weeks, possibly even faster) once you have spun it up. So get your data off it fast if you can.
So SSDs already win in the data retention and reliability-on-reuse department.
I don't understand what you mean by 'non graphics competitors'. Intel, AMD, and ARM cpu offerings already have integrated GPUs with dual-head capability (and have for a few years now). There are no non graphics competitors.
Currently the best open source kernel and driver compatibility is with the Intel and AMD integrated GPUs. That's what all the KMS work was responsible for giving us. The performance of integrated GPUs has increased steadily over the last few years and has reached a point now where most 3D games will run with modest (but not high-end) settings, and *all* 2D (aka desktop operations) will run faster than you can blink.
I splurged for a mid-range card for my windows gaming box, but all my workstations just use the cpu-integrated gpus these days for dual-head operation. And they're nice and quiet and fast.
Well, nobody with a laptop is really going to notice much of a difference because frankly there isn't a whole lot of software that actually needs that kind of performance over the ~550 MBytes/sec that can already be obtained with SATA-III. Certainly not that would be run on a laptop anyway.
It's just using the PCI-e lanes on the M.2 connector instead of the SATA-III lanes. This isn't a magical technology. There's a loss of robustness and portability that gets traded off. It does point to SATA needing another few speed bumps, though. The fundamental serial link technology used at the physical level by PCI-e and SATA is almost identical. The main difference is that SATA is designed for cabling while M.2 is not (at least not M.2's PCI-e lanes).
Nobody does message passing for basic operations. I actually tried to asynchronize DragonFly's system calls once but it was a disaster. Too much overhead.
On a modern Intel cpu a system call runs around 60nS. If you add a message-passing layer with an optimized path to avoid thread switching that will increase to around 200-300ns. If you actually have to switch threads it increases to around 1.2uS. If you actually have to switch threads AND save/restore the FPU state now you are talking about ~2-3uS. If you have to message pass across cpus then the IPI overhead can be significant... several microseconds just for that, plus cache mastership changes.
And all of those times assume shared memory for the message contents. They're strictly the switch and management overhead.
So, basically, no operating system that is intended to run efficiently can use message-passing for basic operations. Message-passing can only be used in two situations:
(1) When you have to switch threads anyway. That is, if two processes or two threads are messaging each other. Another good example is when you schedule an interrupt thread but cannot immediately switch to it (preempt current thread). If the current thread cannot be preempted then the interrupt thread can be scheduled normally without imposing too much overhead vs the alternative.
(2) When the operation can be batched. In DragonFly we successfully use message-passing for network packets and attain very significant cpu localization benefits from it. It works because packets are batched on fast interfaces anyway. By retaining the batching all the way through the protocol stack we can effectively use message passing and spread the overhead across many packets. The improvement we get from cpu localization, particularly not having to acquire or release locks in the protocol paths, then trumps the messaging overhead.
Well... basic procedures using only MOV/CMP/JMP is not something that even linux really needs to code in assembly. What is being talked about here is primarily the trap, exception, syscall, signal trampoline, and interrupt entry and exit mechanisms. Also thread switch code can get pretty complex because there is a lot more hardware state involved than just the basic register set. When you start having to deal with SWAPGS and MSR registers, you've really gone down the rabbit hole.
It's not a major refresh, only a modest one, and it doesn't really fix the readability issues (which would require a complete rewrite). Linux assembly is a mostly unreadable, badly formatted, macro-happy mess. The assembly in the BSDs is much more elegant and minimalistic.
The core of the issue has nothing to do with going off-grid and everything to do with matching production from renewal sources to the actual load on the grid. Without that we get into the situation that Germany finds itself in, which is two fold: (1) That electricity prices fall to zero during the day due to all the solar, and as subsidies go away the owners can't make money from providing power to the grid. And (2) The base load differential between day and night is so great that the traditional generation (i.e. coal) cannot run continuously at critical mass and so becomes extremely inefficient and uneconomical. So coal power generation companies in Germany are also going bankrupt.
Ultimately consumers with PV systems will be forced to pay spot rates and feel the pain. This is already beginning to happen in many parts of the country... where day-time electricity rates are lower but the buy-back is also lower, and night-time rates are higher and have a higher buy-back.
The idea with using the electric car battery (or some other form of temporary storage) is to use it store energy when prices are cheap and inject it into the grid when prices are expensive. This also has the side effect of reducing the base load differential between day and night, so other generation sources such as nuclear and coal can operate efficiently (and thus profitably) to make up the difference.
There is nothing nefarious going on. Really, going entirely off-grid is not something anyone should be trying to do unless they actually live somewhere with a flaky grid (or no grid). And the reality is that electricity prices are going to fluctuate even more between day and night, or rainy vs not, or windy vs not, as more renewable energy sources are brought online.
Depends on a lot of things but one thing for certain... swap on a SSD greatly improves system responsiveness when you have a lot of open applications (on any OS: Windows, Mac, Linux, BSD). Being able to page out anonymous memory to fast swap is a big deal. Nominal file storage on a SSD greatly improves program startup, boot times, photo and document handling. I've found though that it's really having swap space on the SSD that makes the biggest difference. I have a multitude of machines ranging from 1GB to 32GB of ram, with various cpus.
My 2GB haswell-based chomebook is snappy for the tasks I use it for (of course, I replaced the 16G SSD with a 128G SSD and run DragonFly on it). Heck, I even still have an old pre-haswell netbook and throwing a SSD into that made it usable again (but these days I only use it for legacy testing). But I'm really happy with Intel's haswell-or-later based laptop cpus.
There are some caveats. Firefox has huge gaping memory leaks and horrible memory footprint use, so leaving it open in the background for a few days usually builds it up to around ~2GB VSZ and 1.5GB RSS (and it keeps growing. On my 8GB workstation I've let it grow well past 4GB before closing out all the windows and reopening it). If it just paged all that leaked memory out it wouldn't be a problem, but it's so fragmented internally that it winds up touching most of the footprint under normal operation all the time. In this situation, having a bit more memory on the workstation or laptop does help quite a bit.
Another caveat is of course any heavy cpu workloads, such as batch photo or video processing or large compiles. But nobody in their right mind runs that kind of workload on a laptop anyway so.... maybe not so much of an issue.
Other than the browser, there isn't really a whole lot that eats memory to the point where you'd notice it. And beyond photo/video processing, only large compiles really loads down these modern cpus enough to be noticeable.
I started serious programming (at around age 14) on the Pet. First in BASIC, but once I found out you could break into a machine language monitor by wiring up a NMI button (we called it the two-button salute), there began my machine coding. In HEX, directly. Didn't even have a relocator at the beginning. It was a year before I could buy the expansion rom to add disassembly and relocation features to the machine language monitor.
Ultimately I wrote an assmbler too. I don't think I have any of that code any more, it's been lost in time. Kinda makes me sad.
The PETs 8-bit IEEE-488 bus was pretty awesome. The PET had a 1 MHz 6502. The external floppy drive also had a 1 MHz 6502 in it, and you could reprogram it. So one of my many projects was to speed up the data transfer between the two by synchronizing the processors with a series of handshakes and then pushing or pulling the sector data without any further handshakes (using processor timing).
My friend did the same thing for the C64's serial interface (which didn't even have a uart) and sold a product called '1514 Flash!' that sped up the serial interface. Basically a little messing around at the beginning of each transfer to get the two sides synchronized within 1 clock cycle of each other and then pushing/pulling bits as fast as the little cpus would go without any further handshaking. The clocks would stay synchronized long enough to copy a whole sector.
Other projects on the PET... it had a character generator rom which I replaced with a static ram. so when I powered it up I had to load a copy of the original rom into the ram blindly (because the display was total garbage due to it being an uninitialized ram).
The PET had built-in CRT screen but the key was that the data input for the screen was actually a TTL input! So I could pop the wire off the connector and use it like a digital oscilloscope to probe various TTL-based projects (as well as the PET's motherboard itself).
Another project...the character generator rom had something called quarter-block graphics. Basically 16 characters that had all 16 combinations of four quarter-blocks (2x2), so you could (I think) 320x200 graphics on it. I spent many hours optimizing the machine code to generate a pixel pusher.
I got so good at writing editors from scratch, once when I went to computer camp and forgot to bring the tape I rewrote the text editor in machine code in less than an hour.
Met Richard Garriott at that camp too, we were both on staff. He was working on (I think) Ultima II at the time (on an Apple II I think) and had an awesome ram disk for storing code temporarily while he was working on it. Once his computer stopped responding and after unsuccessfully trying to resurrect it he finally gave up and power cycled it, losing his work in the ram disk. It turned out he had accidentally disconnected the keyboard and the computer was actually fine. Oh well! Richard taught a class at that camp on human-interface parsing... basically had people write a dungeon game where you typed in what you wanted to do in English. Primitive of course, but the kids had a blast.
I wrote a centipede game in machine code, incredibly fast and awesome (the last level the centipede was invisible and only blinked into existence for a second or two every few seconds), and submitted it to Cursor magazine. They rejected it because they thought I had stolen it from someone:-(. The only thing I ever tried to get published, rejected because the code was *too* good!
The 6502 had two awesome indirect EA modes. (TABLE,X) and (ADDR),Y, along with the standard modes.
Decimal mode wasn't as interesting, I wound up not using it for display conversion at all.
The 6522 I/O chip was an incredibly powerful chip for its time, with multiple timers and timer-driven events. It had a few bugs, too.
I remember all the unsupported machine codes the 6502 had. It was a hardwired cpu so all instruction codes did *something* (even if it was mostly to just crash the cpu). LDAX was my favorite. Mostly, though, the hidden codes were not very useful.
The list goes on. Twas an awesome time, a time before PCs took over the world.
Not sure what that guy was complaining about but I love my Razer Blackwidow ultimate (2013) keyboard. I grew up on heavy n-key-rollover IBM keyboards and then had to make due with horrible light, cheap, keyboards for many years until I found the Razer. It's worth the price for me. And I've gone through probably 30 or 40 keyboards over the last 35 years.
* Heavy, it doesn't move around.
* USB extension port on the right hand side is perfect for my wireless mouse's transceiver plug.
* N-key rollover that actually works, solid tactile (mechanical) response. I can type at 80+ WPM again.
* And doesn't have thousands of useless extra buttons.
Since a Razer engineer is listening. My suggestions:
* Have a usb port on the left side as well as the right side. * Change the middle-bottom symbol. I don't quite remember... it might have been backlit before and I took the keyboard apart to disconnect it. It was a distraction. * Don't reverse the upper and lower-case symbols on the keycaps. That was kinda silly. * The bottom feet could be a little more robust.
In terms of mice, I use a simple microsoft or logitech wireless mouse now. Simple three button w/wheel... I don't like extra buttons or left/right buttons and when I play games I tend to map most features to the left-hand side of the keyboard rather than to a complex mouse. That way I can bang the mouse around without accidental button pushes. I prefer wired mice but for the last few years I couldn't find any at the stores I frequent.
The wireless mice are fine as long as (A) the tranceiver is within a few inches of the mouse, which it is hanging off the keyboard's RHS usb port. and (B) You use a AA alkaline (non rechargeable) battery. Rechargeable batteries just don't last due to charge leakage. And of course keep a spare battery within reach or replace every month whether or not it needs replacing.
Whenever Radio Shack asked me for my address I just said I wasn't interested in giving it to them. But a friend of mine did one better... he always wrote down the address of the White house and signed it Mickey Mouse. And the sales person dutifully entered it into the computer, no questions asked.
That is not a correct description. Lower frequency radio waves are no less 'quantum' or 'classical' than higher frequency radio waves. AM radios can penetrate objects primarily because they have a wavelength on the order of 400 meters (up to around 1 MHz), whereas FM radios have a wavelength of only a few meters (through around 100 MHz). The longer wavelength of AM effectively allows the radio wave to bypass even relatively large objects such as mountains.
The same effect can be seen even within your house if you have a dual-band WIFI router. The 2.4 GHz band is able to penetrate walls and go around corners and reach the second floor far more easily than the 5 GHz band can.
What morons. Sorry, but they are. They are writing to a file through the operating system which means that it is being spooled out to disk asynchronously, so obviously piecemeal writes are going to be faster because they will run concurrently with the string generation algorithm. Plus their 'writes' are probably being buffered in ram anyway.
Writes to files generally do not stall programs. These people are morons.
No, the ApplePay CC number is not transmitted in any way, only the one-time token is transmitted. If the credit card reader is compromised it is theoretically possible to issue a payment using the one-time token before the payment can be issued by the vendor, but not really practical. And once a payment has been issued the token becomes worthless so the vendor will find out very quickly that they have been compromised (as in, within a few hours, possibly even in real time, rather than months later).
Well, its pretty obvious that the so-called fraud rate is a made-up number. It would be insane if it were true. But most likely... it's insane because the author made it up.
In terms of convenience, ApplePay is about as easy as a contactless credit card. It takes me about 3 seconds to pay with ApplePay and at least for me it's faster than even a contactless card because I keep my phone in a more accessible pocket than I do my wallet.
More importantly, ApplePay is significantly easier to use than chip-and-pin or traditional cards, which is where its competition really is (because that is what most people use in the U.S. who are just now starting to migrate). And also significantly more secure for the user.
It is certainly far more convenient to use than Google Wallet or any Android payment scheme to-date which require you to turn on your phone and/or push into an App to use. Not sure why anyone is even arguing about Google Wallet or other Android pay schemes any more, they've already very obviously have lost that war and will need significant hardware upgrades to even come close to ApplePay's convenience or security.
Touching your wallet to the reader is a bit of a misnomer... works great if you have just one card in your wallet. Doesn't work reliably if you have more than one. Another interesting little tidbit on the contactless payment cards is that if you are standing in line and the person in front of you is paying, and your card is anywhere near the reader, the reader can pick up your card accidently. That has happened to a friend of mine several times, to the point where he now keeps his contactless card in a faraday-cage card slip. That doesn't happen with ApplePay because you have your finger on the fingerprint reader to complete the transaction.
I just squiggle when I have to sign a credit card slip. I don't bother using my signature at all, and haven't for about 20 years (even longer). Nobody cares. I did try using a big 'X' a few times but actually got some pushback on that. But I've never gotten pushback when I use a random scribble.
Well, I think it was a combination of things, and Linux was certainly a part of the reason. But not the whole reason. There are several reasons why Sun finally died:
(1) Sun hardware just couldn't keep up with Intel. The many-threads model really only worked well for parallelization of database operations and not much else. Each individual cpu thread simply became too slow. And people stopped caring about database benchmarks because they were more a function of rapidly improving storage and networking technology than anything else. CPU performance stopped mattering so much and Sun's super-optimized core hardware advantage went right out the door along with it.
(2) Sun's utility software quickly fell behind linux and the BSDs. I began noticing this long before Sun actually sold out to Oracle. Sun's kernel stayed fairly relevant, Solaris wasn't bad... very solid in fact. But competing operating systems were also becoming more solid. But, OMG, the utililties were all 80s crap. Nobody growing up in today's world (or even the world of a decade ago) would be happy with a base Solaris install.
(3) Sun basically became like IBM... corporate only sales and screw making anything that could be bought by up-and-coming students. Solaris for x86 was never taken seriously by Sun, and thus never taken seriously by people outside of Sun. With students growing up on Linux (the younger age group) and the BSDs (my age group), Sun started losing market power as these generational shifts began moving into the workplace. Also, system needs by the web began changing. Sure there are still huge backend databases, but most of the services (and the related hardware) were becoming heavily distributed and Sun's hardware just didn't fit the model.
In fact, this is similar to the problems that SGI had. They were married to their hardware (don't get me started on Solaris for x86), the hardware became non-competitive and unpurchasable by smaller businesses or individuals, and the base software was locked into an 80's snapshot of hell. The system programmers lost sight of what people wanted and got tunnel vision, super-optimizing database paths and ignoring everything else. Problem is, people were more interested in the 'everything else' part.
It might be fine for the older IT types, but all the newcomers had grown up on Linux and the middle-agers had grown up on the BSDs. Their rotation into the workplace spelled Sun's death in very loud, clear terms that Sun pretty much ignored.
While some things have improved in Firefox, much of the browser has gotten worse over time. Simple illustration... it leaks huge amounts of memory. After only 3 days of sitting around:
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
101 164892 1738 128 230 0 1.45G 1.02G - R2L ?? 3d09:44 firefox -geometry +2820+80
After around 2 weeks the machine starts to swap. I've seen the image grow to over 6GB (with 4GB *active*) before I've had to kill it and start a fresh copy. WTF is firefox using all that memory for? It makes no sense whatsoever.
Other problems include severe instability, particularly with the file requestor (when uploading files), which results in seg-faults. And even with all the threading there seem to be severe interdependencies between tabs running javascript, so if one tab is javascript-heavy, it messes up the performance of other tabs.
The menu system is in a complete shambles, and I was really unhappy when the last upgrade changed my default search preferences to Yahoo without so much as a by-your-leave.
Rents in Mountain View for a nice apartment run around $2500/mo. The cost of not having to commute can be high. But there are plenty of other places with relatively good BART access that will run significantly lower. They certainty don't run $7K/month unless you are renting a large house.
Kinda Apples and Oranges. UL testing is fairly straight-forward. The quick explanation - they stress the device in various ways and see if it catches on fire. Checking a crypto setup to a reasonable level of satisfaction can't be done externally. The code for the entire system must be examined, and that is relatively difficult to do.
Linux and the BSDs have been chasing desktop usability for ages. Hell, I've been chasing desktop usability for ages.
Microsoft has it easy. The produce windows and all the laptop, desktop, and server vendors spend hundreds of millions of dollars making sure their designs work with it.
Apple makes their own PCs, they don't have to chase hardware.
And us? Every time a new machine comes out (which is often). A new model, a new chipset, a different combination of on-board devices, whatever.. every single time that happens we developers have to write new drivers or modify existing drivers. We have to work out the kinks, the broken mobo hardware, the broken ACPI implementations, the broken sound hardware that doesn't follow vendor specs or has major exceptions because vendors are lazy. We have to glue the whole mess together not just once. Not just twice. But 20 or 30 times a year. Every year. Forever.
Until that equation changes, the general population simply can't depend on any of our open source code to work on whatever new cool computer they want to buy. And that puts us in the backseat in terms of adoption. Every time.
We can make our stuff work with specific machines, at least if the stars align (that is, if we have the chip specs for the chipsets that have changed and we can write drivers for them fast enough). Making our stuff work with everything, out of the box... it just doesn't happen on a macro scale.
In some small way the collapse of the external chip vendors into a much smaller set of companies has helped. Only two major video companies that we have to worry about now, plus whatever Intel is doing (which they at least provide some specs on now, finally). Only two WIFI chipsets that really matter, maybe three. Only a half dozen ethernet chipset families really matter now. Only two cpu vendors really matter. It's getting better but not because the companies are altruistic. Simply because there are fewer of them and we don't have to write as many drivers or make as many driver mods whenever new hardware comes out. But it isn't enough. Not nearly enough to make us competitive.
That's the #1 problem.
The #2 problem we face is that there is no suitable desktop that works as well as either Windows or Mac desktops. I've tried them all. In linux even. They ALL SUCK. They all break in one way or another and it's just as bad in the linux community as it is in the BSD community due to rampant N.I.H. syndrome. The desktops fail on many levels. Apple doesn't have this problem because Apple enforces a unified ABI for accessing major media subsystems such as audio and video. Microsoft doesn't have this problem either, for the same reason. Linux and the BSDs have no unified ABI, essentially forcing application writers to target their apps to specific user interfaces or hardware subsystems.
It annoys the hell out of me but I don't see anything on the horizon that can really solve the problem.
Slashdot Mirror
Well, except that it isn't a mere month. Unpowered data retention is around 10 years for relatively unworn flash and around 1 year for worn flash. Powered data retention is almost indefinite (doesn't matter if the data is static or not). The modern SSD controller will rewrite blocks as the bits leave the sweet zone.
The main benefit, though, is that SSD wear is essentially based on how much data you've written, which is a very controllable parameter and means, among other things, that even a SSD which has been sitting on a shelf for a long time and lost its data can still be used for fresh data (TRIM wipe + newfs). I have tons of SSDs sitting on a shelf ready to be reused when I need them next. I can't really do that with HDDs and still expect them to be reliable.
Hard drives have a relatively fixed life whether powered or not. If you have a modestly used hard drive and take it out and put it on a shelf for a year, chances are it either won't be able to spin up after that year or it will die relatively quickly (within a few weeks, possibly even faster) once you have spun it up. So get your data off it fast if you can.
So SSDs already win in the data retention and reliability-on-reuse department.
-Matt
I don't understand what you mean by 'non graphics competitors'. Intel, AMD, and ARM cpu offerings already have integrated GPUs with dual-head capability (and have for a few years now). There are no non graphics competitors.
Currently the best open source kernel and driver compatibility is with the Intel and AMD integrated GPUs. That's what all the KMS work was responsible for giving us. The performance of integrated GPUs has increased steadily over the last few years and has reached a point now where most 3D games will run with modest (but not high-end) settings, and *all* 2D (aka desktop operations) will run faster than you can blink.
I splurged for a mid-range card for my windows gaming box, but all my workstations just use the cpu-integrated gpus these days for dual-head operation. And they're nice and quiet and fast.
-Matt
Well, nobody with a laptop is really going to notice much of a difference because frankly there isn't a whole lot of software that actually needs that kind of performance over the ~550 MBytes/sec that can already be obtained with SATA-III. Certainly not that would be run on a laptop anyway.
It's just using the PCI-e lanes on the M.2 connector instead of the SATA-III lanes. This isn't a magical technology. There's a loss of robustness and portability that gets traded off. It does point to SATA needing another few speed bumps, though. The fundamental serial link technology used at the physical level by PCI-e and SATA is almost identical. The main difference is that SATA is designed for cabling while M.2 is not (at least not M.2's PCI-e lanes).
-Matt
Nobody does message passing for basic operations. I actually tried to asynchronize DragonFly's system calls once but it was a disaster. Too much overhead.
On a modern Intel cpu a system call runs around 60nS. If you add a message-passing layer with an optimized path to avoid thread switching that will increase to around 200-300ns. If you actually have to switch threads it increases to around 1.2uS. If you actually have to switch threads AND save/restore the FPU state now you are talking about ~2-3uS. If you have to message pass across cpus then the IPI overhead can be significant... several microseconds just for that, plus cache mastership changes.
And all of those times assume shared memory for the message contents. They're strictly the switch and management overhead.
So, basically, no operating system that is intended to run efficiently can use message-passing for basic operations. Message-passing can only be used in two situations:
(1) When you have to switch threads anyway. That is, if two processes or two threads are messaging each other. Another good example is when you schedule an interrupt thread but cannot immediately switch to it (preempt current thread). If the current thread cannot be preempted then the interrupt thread can be scheduled normally without imposing too much overhead vs the alternative.
(2) When the operation can be batched. In DragonFly we successfully use message-passing for network packets and attain very significant cpu localization benefits from it. It works because packets are batched on fast interfaces anyway. By retaining the batching all the way through the protocol stack we can effectively use message passing and spread the overhead across many packets. The improvement we get from cpu localization, particularly not having to acquire or release locks in the protocol paths, then trumps the messaging overhead.
#2 also works well for data processing pipelines.
-Matt
Well... basic procedures using only MOV/CMP/JMP is not something that even linux really needs to code in assembly. What is being talked about here is primarily the trap, exception, syscall, signal trampoline, and interrupt entry and exit mechanisms. Also thread switch code can get pretty complex because there is a lot more hardware state involved than just the basic register set. When you start having to deal with SWAPGS and MSR registers, you've really gone down the rabbit hole.
-Matt
It's not a major refresh, only a modest one, and it doesn't really fix the readability issues (which would require a complete rewrite). Linux assembly is a mostly unreadable, badly formatted, macro-happy mess. The assembly in the BSDs is much more elegant and minimalistic.
-Matt
The core of the issue has nothing to do with going off-grid and everything to do with matching production from renewal sources to the actual load on the grid. Without that we get into the situation that Germany finds itself in, which is two fold: (1) That electricity prices fall to zero during the day due to all the solar, and as subsidies go away the owners can't make money from providing power to the grid. And (2) The base load differential between day and night is so great that the traditional generation (i.e. coal) cannot run continuously at critical mass and so becomes extremely inefficient and uneconomical. So coal power generation companies in Germany are also going bankrupt.
Ultimately consumers with PV systems will be forced to pay spot rates and feel the pain. This is already beginning to happen in many parts of the country... where day-time electricity rates are lower but the buy-back is also lower, and night-time rates are higher and have a higher buy-back.
The idea with using the electric car battery (or some other form of temporary storage) is to use it store energy when prices are cheap and inject it into the grid when prices are expensive. This also has the side effect of reducing the base load differential between day and night, so other generation sources such as nuclear and coal can operate efficiently (and thus profitably) to make up the difference.
There is nothing nefarious going on. Really, going entirely off-grid is not something anyone should be trying to do unless they actually live somewhere with a flaky grid (or no grid). And the reality is that electricity prices are going to fluctuate even more between day and night, or rainy vs not, or windy vs not, as more renewable energy sources are brought online.
-Matt
Depends on a lot of things but one thing for certain... swap on a SSD greatly improves system responsiveness when you have a lot of open applications (on any OS: Windows, Mac, Linux, BSD). Being able to page out anonymous memory to fast swap is a big deal. Nominal file storage on a SSD greatly improves program startup, boot times, photo and document handling. I've found though that it's really having swap space on the SSD that makes the biggest difference. I have a multitude of machines ranging from 1GB to 32GB of ram, with various cpus.
My 2GB haswell-based chomebook is snappy for the tasks I use it for (of course, I replaced the 16G SSD with a 128G SSD and run DragonFly on it). Heck, I even still have an old pre-haswell netbook and throwing a SSD into that made it usable again (but these days I only use it for legacy testing). But I'm really happy with Intel's haswell-or-later based laptop cpus.
There are some caveats. Firefox has huge gaping memory leaks and horrible memory footprint use, so leaving it open in the background for a few days usually builds it up to around ~2GB VSZ and 1.5GB RSS (and it keeps growing. On my 8GB workstation I've let it grow well past 4GB before closing out all the windows and reopening it). If it just paged all that leaked memory out it wouldn't be a problem, but it's so fragmented internally that it winds up touching most of the footprint under normal operation all the time. In this situation, having a bit more memory on the workstation or laptop does help quite a bit.
Another caveat is of course any heavy cpu workloads, such as batch photo or video processing or large compiles. But nobody in their right mind runs that kind of workload on a laptop anyway so.... maybe not so much of an issue.
Other than the browser, there isn't really a whole lot that eats memory to the point where you'd notice it. And beyond photo/video processing, only large compiles really loads down these modern cpus enough to be noticeable.
-Matt
char
EncryptChar(char x)
{
return 0;
}
I started serious programming (at around age 14) on the Pet. First in BASIC, but once I found out you could break into a machine language monitor by wiring up a NMI button (we called it the two-button salute), there began my machine coding. In HEX, directly. Didn't even have a relocator at the beginning. It was a year before I could buy the expansion rom to add disassembly and relocation features to the machine language monitor.
Ultimately I wrote an assmbler too. I don't think I have any of that code any more, it's been lost in time. Kinda makes me sad.
The PETs 8-bit IEEE-488 bus was pretty awesome. The PET had a 1 MHz 6502. The external floppy drive also had a 1 MHz 6502 in it, and you could reprogram it. So one of my many projects was to speed up the data transfer between the two by synchronizing the processors with a series of handshakes and then pushing or pulling the sector data without any further handshakes (using processor timing).
My friend did the same thing for the C64's serial interface (which didn't even have a uart) and sold a product called '1514 Flash!' that sped up the serial interface. Basically a little messing around at the beginning of each transfer to get the two sides synchronized within 1 clock cycle of each other and then pushing/pulling bits as fast as the little cpus would go without any further handshaking. The clocks would stay synchronized long enough to copy a whole sector.
Other projects on the PET... it had a character generator rom which I replaced with a static ram. so when I powered it up I had to load a copy of the original rom into the ram blindly (because the display was total garbage due to it being an uninitialized ram).
The PET had built-in CRT screen but the key was that the data input for the screen was actually a TTL input! So I could pop the wire off the connector and use it like a digital oscilloscope to probe various TTL-based projects (as well as the PET's motherboard itself).
Another project...the character generator rom had something called quarter-block graphics. Basically 16 characters that had all 16 combinations of four quarter-blocks (2x2), so you could (I think) 320x200 graphics on it. I spent many hours optimizing the machine code to generate a pixel pusher.
I got so good at writing editors from scratch, once when I went to computer camp and forgot to bring the tape I rewrote the text editor in machine code in less than an hour.
Met Richard Garriott at that camp too, we were both on staff. He was working on (I think) Ultima II at the time (on an Apple II I think) and had an awesome ram disk for storing code temporarily while he was working on it. Once his computer stopped responding and after unsuccessfully trying to resurrect it he finally gave up and power cycled it, losing his work in the ram disk. It turned out he had accidentally disconnected the keyboard and the computer was actually fine. Oh well! Richard taught a class at that camp on human-interface parsing... basically had people write a dungeon game where you typed in what you wanted to do in English. Primitive of course, but the kids had a blast.
I wrote a centipede game in machine code, incredibly fast and awesome (the last level the centipede was invisible and only blinked into existence for a second or two every few seconds), and submitted it to Cursor magazine. They rejected it because they thought I had stolen it from someone :-(. The only thing I ever tried to get published, rejected because the code was *too* good!
The 6502 had two awesome indirect EA modes. (TABLE,X) and (ADDR),Y, along with the standard modes.
Decimal mode wasn't as interesting, I wound up not using it for display conversion at all.
The 6522 I/O chip was an incredibly powerful chip for its time, with multiple timers and timer-driven events. It had a few bugs, too.
I remember all the unsupported machine codes the 6502 had. It was a hardwired cpu so all instruction codes did *something* (even if it was mostly to just crash the cpu). LDAX was my favorite. Mostly, though, the hidden codes were not very useful.
The list goes on. Twas an awesome time, a time before PCs took over the world.
-Matt
SSD $/GB is gonna be going down across the board. It's nice to see the competition heat up.
-Matt
Not sure what that guy was complaining about but I love my Razer Blackwidow ultimate (2013) keyboard. I grew up on heavy n-key-rollover IBM keyboards and then had to make due with horrible light, cheap, keyboards for many years until I found the Razer. It's worth the price for me. And I've gone through probably 30 or 40 keyboards over the last 35 years.
* Heavy, it doesn't move around.
* USB extension port on the right hand side is perfect for my wireless mouse's transceiver plug.
* N-key rollover that actually works, solid tactile (mechanical) response. I can type at 80+ WPM again.
* And doesn't have thousands of useless extra buttons.
Since a Razer engineer is listening. My suggestions:
* Have a usb port on the left side as well as the right side.
* Change the middle-bottom symbol. I don't quite remember... it might have been backlit before and I took the keyboard apart to disconnect it. It was a distraction.
* Don't reverse the upper and lower-case symbols on the keycaps. That was kinda silly.
* The bottom feet could be a little more robust.
In terms of mice, I use a simple microsoft or logitech wireless mouse now. Simple three button w/wheel... I don't like extra buttons or left/right buttons and when I play games I tend to map most features to the left-hand side of the keyboard rather than to a complex mouse. That way I can bang the mouse around without accidental button pushes. I prefer wired mice but for the last few years I couldn't find any at the stores I frequent.
The wireless mice are fine as long as (A) the tranceiver is within a few inches of the mouse, which it is hanging off the keyboard's RHS usb port. and (B) You use a AA alkaline (non rechargeable) battery. Rechargeable batteries just don't last due to charge leakage. And of course keep a spare battery within reach or replace every month whether or not it needs replacing.
-Matt
Whenever Radio Shack asked me for my address I just said I wasn't interested in giving it to them. But a friend of mine did one better... he always wrote down the address of the White house and signed it Mickey Mouse. And the sales person dutifully entered it into the computer, no questions asked.
-Matt
That is not a correct description. Lower frequency radio waves are no less 'quantum' or 'classical' than higher frequency radio waves. AM radios can penetrate objects primarily because they have a wavelength on the order of 400 meters (up to around 1 MHz), whereas FM radios have a wavelength of only a few meters (through around 100 MHz). The longer wavelength of AM effectively allows the radio wave to bypass even relatively large objects such as mountains.
The same effect can be seen even within your house if you have a dual-band WIFI router. The 2.4 GHz band is able to penetrate walls and go around corners and reach the second floor far more easily than the 5 GHz band can.
-Matt
What morons. Sorry, but they are. They are writing to a file through the operating system which means that it is being spooled out to disk asynchronously, so obviously piecemeal writes are going to be faster because they will run concurrently with the string generation algorithm. Plus their 'writes' are probably being buffered in ram anyway.
Writes to files generally do not stall programs. These people are morons.
-Matt
No, the ApplePay CC number is not transmitted in any way, only the one-time token is transmitted. If the credit card reader is compromised it is theoretically possible to issue a payment using the one-time token before the payment can be issued by the vendor, but not really practical. And once a payment has been issued the token becomes worthless so the vendor will find out very quickly that they have been compromised (as in, within a few hours, possibly even in real time, rather than months later).
-Matt
Well, its pretty obvious that the so-called fraud rate is a made-up number. It would be insane if it were true. But most likely... it's insane because the author made it up.
-Matt
In terms of convenience, ApplePay is about as easy as a contactless credit card. It takes me about 3 seconds to pay with ApplePay and at least for me it's faster than even a contactless card because I keep my phone in a more accessible pocket than I do my wallet.
More importantly, ApplePay is significantly easier to use than chip-and-pin or traditional cards, which is where its competition really is (because that is what most people use in the U.S. who are just now starting to migrate). And also significantly more secure for the user.
It is certainly far more convenient to use than Google Wallet or any Android payment scheme to-date which require you to turn on your phone and/or push into an App to use. Not sure why anyone is even arguing about Google Wallet or other Android pay schemes any more, they've already very obviously have lost that war and will need significant hardware upgrades to even come close to ApplePay's convenience or security.
Touching your wallet to the reader is a bit of a misnomer... works great if you have just one card in your wallet. Doesn't work reliably if you have more than one. Another interesting little tidbit on the contactless payment cards is that if you are standing in line and the person in front of you is paying, and your card is anywhere near the reader, the reader can pick up your card accidently. That has happened to a friend of mine several times, to the point where he now keeps his contactless card in a faraday-cage card slip. That doesn't happen with ApplePay because you have your finger on the fingerprint reader to complete the transaction.
-Matt
I just squiggle when I have to sign a credit card slip. I don't bother using my signature at all, and haven't for about 20 years (even longer). Nobody cares. I did try using a big 'X' a few times but actually got some pushback on that. But I've never gotten pushback when I use a random scribble.
-Matt
Wish more people would leave, its getting crowded here. But, alas, idiotic opinions on slashdot don't translate into reality.
-Matt
Well, I think it was a combination of things, and Linux was certainly a part of the reason. But not the whole reason. There are several reasons why Sun finally died:
(1) Sun hardware just couldn't keep up with Intel. The many-threads model really only worked well for parallelization of database operations and not much else. Each individual cpu thread simply became too slow. And people stopped caring about database benchmarks because they were more a function of rapidly improving storage and networking technology than anything else. CPU performance stopped mattering so much and Sun's super-optimized core hardware advantage went right out the door along with it.
(2) Sun's utility software quickly fell behind linux and the BSDs. I began noticing this long before Sun actually sold out to Oracle. Sun's kernel stayed fairly relevant, Solaris wasn't bad... very solid in fact. But competing operating systems were also becoming more solid. But, OMG, the utililties were all 80s crap. Nobody growing up in today's world (or even the world of a decade ago) would be happy with a base Solaris install.
(3) Sun basically became like IBM... corporate only sales and screw making anything that could be bought by up-and-coming students. Solaris for x86 was never taken seriously by Sun, and thus never taken seriously by people outside of Sun. With students growing up on Linux (the younger age group) and the BSDs (my age group), Sun started losing market power as these generational shifts began moving into the workplace. Also, system needs by the web began changing. Sure there are still huge backend databases, but most of the services (and the related hardware) were becoming heavily distributed and Sun's hardware just didn't fit the model.
In fact, this is similar to the problems that SGI had. They were married to their hardware (don't get me started on Solaris for x86), the hardware became non-competitive and unpurchasable by smaller businesses or individuals, and the base software was locked into an 80's snapshot of hell. The system programmers lost sight of what people wanted and got tunnel vision, super-optimizing database paths and ignoring everything else. Problem is, people were more interested in the 'everything else' part.
It might be fine for the older IT types, but all the newcomers had grown up on Linux and the middle-agers had grown up on the BSDs. Their rotation into the workplace spelled Sun's death in very loud, clear terms that Sun pretty much ignored.
-Matt
While some things have improved in Firefox, much of the browser has gotten worse over time. Simple illustration... it leaks huge amounts of memory. After only 3 days of sitting around:
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
101 164892 1738 128 230 0 1.45G 1.02G - R2L ?? 3d09:44 firefox -geometry +2820+80
After around 2 weeks the machine starts to swap. I've seen the image grow to over 6GB (with 4GB *active*) before I've had to kill it and start a fresh copy. WTF is firefox using all that memory for? It makes no sense whatsoever.
Other problems include severe instability, particularly with the file requestor (when uploading files), which results in seg-faults. And even with all the threading there seem to be severe interdependencies between tabs running javascript, so if one tab is javascript-heavy, it messes up the performance of other tabs.
The menu system is in a complete shambles, and I was really unhappy when the last upgrade changed my default search preferences to Yahoo without so much as a by-your-leave.
-Matt
Rents in Mountain View for a nice apartment run around $2500/mo. The cost of not having to commute can be high. But there are plenty of other places with relatively good BART access that will run significantly lower. They certainty don't run $7K/month unless you are renting a large house.
-Matt
Kinda Apples and Oranges. UL testing is fairly straight-forward. The quick explanation - they stress the device in various ways and see if it catches on fire. Checking a crypto setup to a reasonable level of satisfaction can't be done externally. The code for the entire system must be examined, and that is relatively difficult to do.
-Matt
Linux and the BSDs have been chasing desktop usability for ages. Hell, I've been chasing desktop usability for ages.
Microsoft has it easy. The produce windows and all the laptop, desktop, and server vendors spend hundreds of millions of dollars making sure their designs work with it.
Apple makes their own PCs, they don't have to chase hardware.
And us? Every time a new machine comes out (which is often). A new model, a new chipset, a different combination of on-board devices, whatever.. every single time that happens we developers have to write new drivers or modify existing drivers. We have to work out the kinks, the broken mobo hardware, the broken ACPI implementations, the broken sound hardware that doesn't follow vendor specs or has major exceptions because vendors are lazy. We have to glue the whole mess together not just once. Not just twice. But 20 or 30 times a year. Every year. Forever.
Until that equation changes, the general population simply can't depend on any of our open source code to work on whatever new cool computer they want to buy. And that puts us in the backseat in terms of adoption. Every time.
We can make our stuff work with specific machines, at least if the stars align (that is, if we have the chip specs for the chipsets that have changed and we can write drivers for them fast enough). Making our stuff work with everything, out of the box... it just doesn't happen on a macro scale.
In some small way the collapse of the external chip vendors into a much smaller set of companies has helped. Only two major video companies that we have to worry about now, plus whatever Intel is doing (which they at least provide some specs on now, finally). Only two WIFI chipsets that really matter, maybe three. Only a half dozen ethernet chipset families really matter now. Only two cpu vendors really matter. It's getting better but not because the companies are altruistic. Simply because there are fewer of them and we don't have to write as many drivers or make as many driver mods whenever new hardware comes out. But it isn't enough. Not nearly enough to make us competitive.
That's the #1 problem.
The #2 problem we face is that there is no suitable desktop that works as well as either Windows or Mac desktops. I've tried them all. In linux even. They ALL SUCK. They all break in one way or another and it's just as bad in the linux community as it is in the BSD community due to rampant N.I.H. syndrome. The desktops fail on many levels. Apple doesn't have this problem because Apple enforces a unified ABI for accessing major media subsystems such as audio and video. Microsoft doesn't have this problem either, for the same reason. Linux and the BSDs have no unified ABI, essentially forcing application writers to target their apps to specific user interfaces or hardware subsystems.
It annoys the hell out of me but I don't see anything on the horizon that can really solve the problem.
-Matt