Well, you can try using a SD card for general storage. Good luck with the extremely poor random write performance and lack of redundancy most of those cards are going to have. They are designed for cameras and cell phones and will generally die very quickly if you write-cycle them as much as you would a normal filesystem. The SD card hardware isn't even queued. For that matter the USB memory sticks aren't that much better. They are better... just not much better.
My preference for external storage is to actually carry along a 2.5" SATA SSD and a SATA->USB adapter. Very high performance reading and writing, both random and sequential, and I can just stuff the SSD into a hot-swap slot on my workstation when I get home.
There are two major SD card form factors, three if you include compact flash. There are two major USB connectors for computers (USB and USB-C, not including two the two micro-usb form factors or the large square 'device' connectors). There are *five* video form factors, four of which are still current (DVI, HDMI, DP, Mini-DP).
So he has a point. However, the new macbook-pro goes too far in removing ports. Standard USB ports are still *extremely* useful and for a laptop having a bunch of them is also extremely useful. They removed the separate power port, which basically means there is only one USB-C port available for peripherals.
There's no point if its too expensive, or if the durability is 25 years (which destroys the whole payback equation). This is kinda like the power-wall. Great concept, but the technology isn't quite there yet. And it may not be quite there for solar roofing tiles either.
Speaking of which, several companies tried selling solar roofing tiles in the past, and had to give up on lack of sales. It isn't a new technology. The question is... is it good enough to hit the necessary sweet spot? My guess... probably not yet.
I have a System76, but honestly I barely use it because it is loud and it has the worst laptop keyboard I've ever encountered (the key spacing is designed for people with HUUUGE hands and any lateral force causes the key to stick and not go down, making typing nearly impossible). And the battery life aint too hot either. The System76 is powerful, but inconvenient. I actually prefer my chromebook, which is much smaller (smaller screen, lower resolution, much less ram, much slower cpu, etc)... but far more usable.
Apple stuff is expensive, but I wonder about people who complain about base specs all the time. 'more' is not necessarily 'better'. My dinky little chromebook has only 4G of ram but I don't even feel it when it pages to/from its SSD. There's no point stuffing 32GB of ram into a laptop, frankly. It's just a waste of power (and money).
I will of course stuff as much ram into a box as is economically feasible, just because I'm me. I have a dual-socket xeon system with 128GB of ram, for example, and I have a broadwell desktop with 64GB of ram. Both are being used as servers and build boxes at the moment.
But the box I currently use for my workstation only has 8GB of ram and I don't feel the paging to/from the SSD even with tons of Chrome windows leaking memory all over the place so I have been in no hurry to replace. In fact, my workstation is just a dinky old Haswell i3 box, and yet it has no problem driving two 4K monitors or playing video. It wouldn't win any prizes playing games, but then again I don't use it to play games.
Update to present-day NVMe SSDs, which have ~3-5x the read performance of a SATA SSD, and I kinda wonder where these complaints come from.
Satellite pagers (and in more modern times, texts over the cellular network) are the most reliable way to get alarms out to field and on-call personal. Sure, someone could send a malicious fake page or text, but these alarms are mainly just heads-up to personal who are not in the operations center that something is amis. The main board will always be checked / personal will always call in and double check before anyone actually pushes any buttons.
I have two major beefs with IPV6. The first is that the end-point 2^48 switch address space wasn't well thought-through. Hey, wouldn't it be great if we didn't have to use NAT and give all of those IOT devices their own IPV6 address? Well... no actually, NAT does a pretty good job of obscuring the internal topology of the end-point network. Just having a statefull firewall and no NAT exposes the internal topology. Not such a good idea.
The second is that all the discovery protocols were left unencrypted and made complex enough to virtually guarantee a plethora of possible exploits. Some have been discovered and fixed, I guarantee there are many more in the wings. IPV4 security is a well known problem with well known solutions. IPV6 security is a different beast entirely.
Other problems including the excessively flexible protocol layering allowing for all sorts of encapsulation tricks (some of which have already been demonstrated), pasting on a 'mandatory' IPSEC without integration with a mandatory secure validation framework (making it worthless w/regards to generic applications being able to assert a packet-level secure connection), assumptions that the address space would be too big to scan (yah right... the hackers didn't get that memo my tcpdump tells me), not making use of MAC-layer features that would have improved local LAN security, if only a little. Also idiotically and arbitrarily blocking off a switch subspace, eating 48 bits for no good reason and trying to disallow routing within that space (which will soon have to be changed considering that number of people who want to have stateful *routers* to break up their sub-48-bit traffic and who have no desire whatsoever to treat those 48 bits as one big switched sub-space).
The list goes on. But now we are saddled with this pile, so we have to deal with it.
There is no flood defense possible for most businesses at the tail-end of the pipe. When an attacker pushes a terrabit/s at you and at all the routers in the path leading to you as well as other leafs that terminate at those routers, from 3 million different IP addresses from compromised IOT devices, your internet pipes are dead, no matter how much redundancy you have.
Only the biggest companies out there can handle these kinds of attacks. The backbone providers have some defenses, but it isn't as simple as just blocking a few IPs.
You just use the scroll-wheel. The scroll bar is always a last resort. I prefer the scroll-wheel myself, but if the system doesn't have a mouse -- that is, one only has the trackpad, then either two-finger scrolling (Apple style) or one-finger-right-side-of-pad scrolling is a pretty good substitute.
The real problem is the touchpad hardware. The touchpad device itself may not be able to accurately track three or four fingers, and there isn't a thing the operating system can do to fix it. I've noticed this on chromebooks, in particular when I ported the touchpad driver for the Acer C720. The hardware gets very confused if you put more than two fingers down on the pad horizontally (or you cross them horizontally while you slide your fingers around).
It basically makes using more than two fingers very unreliable. My presumption is that a lot of laptops out there with these pads probably have the same hardware limitations.
Unless the project has only one source file, compiling isn't really single-thread bound. Most projects can be built make -j N. When we do bulk builds, that's what we see happening most of the time so with very few exceptions your project builds should be able to make use of many cpu cores at once.
The few exceptions are: (1) The link phase is typically a choke point and serializes to one thread, and (2) Certain source files might be so large relative to the others that everything else finishes and the build is twiddling its thumbs waiting for that one 200,000 line source file to finish compiling before it can move on to the link phase.
One other note - Builds are like 99.9% cpu driven. Storage bandwidth is almost irrelevant because there is almost no I/O involved in doing a build vs the cpu time required. Source files are already likely cached in memory. Temporary files don't last long enough to even have a chance to get written to disk (if not using tmpfs), and object files and executables are tiny relative to available storage bandwidth and asynchronously flushed as well (so nobody has to wait on them to be flushed to disk).
So, for example, when we do a bulk build of all 24000+ applications in ports, we use tmpfs mounts for all temporary files and our disk I/O is almost non-existent throughout the process. The only time we see busy storage is during maximum peak load when the running compiler binaries exceed available ram and the system pages a bit (you have to allow this in order to optimize the non-peak portions of the build to ensure that all system resources are fully utilized throughout the entire 22-hour-long bulk build).
Yes, but that is what the XPoint technology is trying to address. The NVMe technology is not designed to operate like ram and the latencies are still very high. Nominal NVMe latency for a random access is 15-30uS. The performance (1.5-3.0 GBytes/sec for normal and 5 GBytes/sec+ for high-end NVMe devices, reading) comes from the multi-queue design allowing many requests to be queued at the same time.
Very few workloads would be able to attain the required request concurrency to actually max-out a NVMe device. You have to have something like 64-128 random requests outstanding to max-out the bandwidth (fewer for sequential). Server-side services have no problem doing this, but very few consumer apps can take full advantage of it.
The NVMe design is thus more akin to being a fast storage controller and should not be considered similar to a dynamic ram controller in terms of performance capability.
Because of the request concurrency required to actually attain the high read capability of a NVMe device, people shouldn't throw away their SATA SSDs just yet. Most SATA SSDs will actually have higher write bandwidth than low-end NVMe devices (particularly small form factor NVMe devices). And for a lot of (particularly consumer) workloads, the NVMe SSD will not be a whole lot faster.
That said, I really love NVMe, particularly when configured as swap and/or a swap-based disk cache. And I love it even more as a primary filesystem. It's so fast that I've had to redesign numerous code paths in DragonFlyBSD to be able to take full advantage of it. For example, the buffer cache and VM page queue (pageout demon) code was never designed for a data read rate of 5 GBytes/sec. Think about what 5+ GBytes/sec of new file-backed VM pages being instantiated per second does to normal VM page queue algorithms which normally only keep a few hundred megabytes of completely free pages in PG_FREE. The pageout demon couldn't recycle pages fast enough to keep up!
I should add, the evidence of this is plentiful. Anyone remember the days of IDE PIO ? Before IDE DMA and in particular before command and data blocks could be fully buffered by a hardware FIFO in the control, IDE PIO was a complete disaster. It barely worked (and quite often didn't). And we had to pull out the stops as device driver writers to get it work as well as it did (which wasn't very well).
Not quite true A.C. The instructions for those old 8-bit CPUs could be synchronized down to a single clock tick (basically crystal accuracy), thus allowing perfect read and write sampling of I/O directly. We could do direct synthesis and A/D sampling, for example, with no cycle error, as well as synchronize data streams and then burst data with no further handshaking. It is impossible to do that with a modern CPU, so anything which requires crystal-accurate output has to be offloaded to (typically an FPGA).
RTOSs only work up to a point, particularly because modern CPUs have supervisory interrupts (well, Intel at least has the SMI) which throw a wrench into the works. But also because it is literally impossible to count cycles for how long something will take. A modern RTOS works at a much higher level than the RTOSs and is unable to provide the same rock solid guarantees that the 8-bit RTOSs could.
Looks interesting... I've pre-ordered two (both cpu models, 4G) for DragonFlyBSD, we'll get it working on them. Dunno about the SD card, but a PCIe SSD would certainly work. BIOS is usually the sticking point on these types of devices. Our graphics stack isn't quite up to Braswell yet but it might work in frame buffer mode (without accel). We'll see. The rest of it is all standard intel insofar as drivers are concerned.
My network dev says the Gigabit controller is crap:-) (he's very particular). But for a low-end device like this nobody will care.
All the rest of the I/O is basically just pinned out from the Intel cpu. Always fun to remark on specs, but these days specs are mostly just what the cpu chip/chipset supports directly.
I'm amused that some people in other comments are so indignant about the pricing. Back in the day, those of us who hacked on computers (Commodore, Atari, TRS-80, Apple-II, later the Amiga, etc) saved up and spent what would be equivalent to a few thousand dollars (in today's dollars) to purchase our boxes. These days enthusiast devices are *cheap* by comparison. My PET came with 16KB of ram and a tape cassette recorder for storage, and I later expanded it to 32KB and thought it was godly.
What new and relevant thing do you want to see in the phone? I for one can't really think of anything. I don't really need a better camera, for example, nor do I need any on-phone storage. LTE (or LTE-A) is plenty fast enough, no point having more bandwidth that I'm not going to pay the cell carrier for. Wifi is plenty fast enough. Games run fine on the -6 so they'll run fine on the -7. What's left?
Apple has lost an idiot as a customer? Probably not a big loss. Nobody is forcing you to buy a wireless handset and nothing is stopping you from trying out the adapter in an Apple Store to check the quality when it comes out.
So full of complete nonsense. Throwing out terms without knowing what they actually mean, let alone whether an operating system actually has to make any changes to support it.
Take speed-shift for example... all it does is remove the need for the OS to calculate a P-state for HLT/MWAIT. All ACPI has to do is present a smaller list of P states and *ANY* OS that supports HLT/MWAIT p-state setting (which basically worked meaningfully from Haswell onward) will instantly be using SpeedShift. There's nothing to 'support' unless the OS is coded to intentionally break it.
AMD's SMT improvements don't need any OS-specific coding. The original bulldozer architecture *DID* need OS-specific coding, because it was a piece of shit (and a lot of us just didn't bother to code the OS to try to characterized mixed integer/FP loads), but continuing to use that coding in the newer architecture doesn't really cost anything. And, again, the CPU topology is made available to the OS via ACPI, and any OS since before Sandybridge could use it. Linux and the BSDs have been using the topology info provided by ACPI for years, and Microsoft had better have been too, so no specific OS coding is required.
Firefox has been extremely unstable for us for at least the last year. Finally putting a process behind each tab is an important step, certainly, but its one they should have implemented 2+ years ago. I also really wish Mozilla would stop with all the useless bells and whistles that nobody uses and instead focus on stabilizing the code they have.
My recommendation... switch to chrome. It's a much better browser.
Is... can I run DragonFly on it? Or is the BIOS locked to Chrome ? If this baby has the normal write-protect screw / developer mode BIOS features that allow us to run whatever we want on it instead of being locked to chrome, then great!
We've had great success with the older Acer C720[P] (running a mobile haswell cpu) running DragonFly. So if one of these new HP Skylake-m babies allows me to cut into the dance then I'll give it a big thumbs up.
I will impart a warning here. I have a friend who has repeatedly tried to use non-Apple batteries in his Apple mobile devices and its been a dismal failure for him. Spend the money to have Apple replace your battery, you will be happier in the end.
Apple laptops... well, the ones with replaceable batteries are a different story. Going third-party there works fairly well. The ones that don't... again spend the money to have Apple do it for you, you will be happier in the end.
Another recommendation... when possible, always leave your devices plugged in. This causes the Apple battery management software to properly load cycle the full battery and will significantly increase battery life. I usually bring along an external battery and just keep my phone plugged in whenever possible for that very reason (when convenient).
My ipad-1's battery is still in great shape (now going on 6 years old), though the ipad-1 itself doesn't have enough memory to really be able to run much any more. My ipad-2 as well. 512M of ram isn't enough to run apps smoothly any more on the ipad-2 (and the ipad-1 can barely run anything), but the battery is in great shape because I leave the devices plugged in as much as possible.
Perhaps not one key event, but a combination of solid state storage removing the hard-drive-failure event that often drove people to upgrade, CPU performance topping out, and RAM well beyond anything most programs need have all conspired together to give us desktops, laptops, and mobile devices that basically no longer get 'old'. Not to mention that power consumption is low enough now that PSUs just aren't burning out like they used to:-).
Something strange happened in the last year or two. I buy computers all the time for DragonFly testing, so I have a pile of machines of all different kinds including a bunch of BRIX form-factor units. I stuff nominal sweet-spot memory and storage into them all, always, because they get repurposed or farmed out to friends all the time to make room for new hw.
The strange thing that happened... it became convenient to just throw 8-16GB of ram into all of these things. Even the tiny little BRIX. And even the little BRIX can dual-head two 4K displays, and easily fit a 2.5" SSD (and so can hold quite a bit of storage). None of these boxes have any moving components except a fan or two. They don't fail if I put them on a shelf for a year.
Up until about 2 years ago I was regularly throwing away my oldest hardware, including the bulky cases (which had to be large enough to hold a CD and/or DVD and several 3.5" drives).
But the remainder of that really old hardware petered out last year. Now there's no reason at all to throw away my 'new' old hardware... it is still useful enough that I can give it away or repurpose some of its components. The cases are all small so I just reuse those if I can't find any use for the mobo. I reuse the SSDs (I never reused old hard drives). I reuse the PSUs (if any). There's no graphics card to replace since it is built into the cpu.
In fact, the only thing I haven't been able to recycle in the new old machines have been the DIMMs due to continuous technology changes, but those just stay with the original motherboard.
In our colocation for DragonFly our blade server (12 x haswell blades in 2U) has handled all of our needs and other than slowly replacing the remaining HDDs with SSDs will probably handle all of our needs for the next 10 years. Or longer. It will be interesting to see what the failure mode is for the hardware because it will probably be the first piece of hardware I own that stays fully active and relevant until the blades actually physically fail.
I love the technology but I think there's only more pain to come for Intel.
Which is why I run the cable box into a dedicated ethernet port on the server and run a point-to-point VPN to a colo. Comcast aint gonna be snooping much:-) Nor will Verizon, since I drill an openvpn link to the colo from my phone as well.
... is to disable all of its smarts. If you value your privacy, don't let it connect to the internet!
I'll take a regular 4K monitor without any bells and whistles thank you very much. And if it has a microphone or camera built into it that will be the first thing I stick my soldering iron into before I begin using it for real. Gouge out its eyes and ears, and we're good.
Slashdot Mirror
Well, you can try using a SD card for general storage. Good luck with the extremely poor random write performance and lack of redundancy most of those cards are going to have. They are designed for cameras and cell phones and will generally die very quickly if you write-cycle them as much as you would a normal filesystem. The SD card hardware isn't even queued. For that matter the USB memory sticks aren't that much better. They are better... just not much better.
My preference for external storage is to actually carry along a 2.5" SATA SSD and a SATA->USB adapter. Very high performance reading and writing, both random and sequential, and I can just stuff the SSD into a hot-swap slot on my workstation when I get home.
-Matt
There are two major SD card form factors, three if you include compact flash. There are two major USB connectors for computers (USB and USB-C, not including two the two micro-usb form factors or the large square 'device' connectors). There are *five* video form factors, four of which are still current (DVI, HDMI, DP, Mini-DP).
So he has a point. However, the new macbook-pro goes too far in removing ports. Standard USB ports are still *extremely* useful and for a laptop having a bunch of them is also extremely useful. They removed the separate power port, which basically means there is only one USB-C port available for peripherals.
To say it is stupid is not being critical enough.
-Matt
There's no point if its too expensive, or if the durability is 25 years (which destroys the whole payback equation). This is kinda like the power-wall. Great concept, but the technology isn't quite there yet. And it may not be quite there for solar roofing tiles either.
Speaking of which, several companies tried selling solar roofing tiles in the past, and had to give up on lack of sales. It isn't a new technology. The question is... is it good enough to hit the necessary sweet spot? My guess... probably not yet.
-Matt
I have a System76, but honestly I barely use it because it is loud and it has the worst laptop keyboard I've ever encountered (the key spacing is designed for people with HUUUGE hands and any lateral force causes the key to stick and not go down, making typing nearly impossible). And the battery life aint too hot either. The System76 is powerful, but inconvenient. I actually prefer my chromebook, which is much smaller (smaller screen, lower resolution, much less ram, much slower cpu, etc)... but far more usable.
Apple stuff is expensive, but I wonder about people who complain about base specs all the time. 'more' is not necessarily 'better'. My dinky little chromebook has only 4G of ram but I don't even feel it when it pages to/from its SSD. There's no point stuffing 32GB of ram into a laptop, frankly. It's just a waste of power (and money).
I will of course stuff as much ram into a box as is economically feasible, just because I'm me. I have a dual-socket xeon system with 128GB of ram, for example, and I have a broadwell desktop with 64GB of ram. Both are being used as servers and build boxes at the moment.
But the box I currently use for my workstation only has 8GB of ram and I don't feel the paging to/from the SSD even with tons of Chrome windows leaking memory all over the place so I have been in no hurry to replace. In fact, my workstation is just a dinky old Haswell i3 box, and yet it has no problem driving two 4K monitors or playing video. It wouldn't win any prizes playing games, but then again I don't use it to play games.
Update to present-day NVMe SSDs, which have ~3-5x the read performance of a SATA SSD, and I kinda wonder where these complaints come from.
-Matt
Satellite pagers (and in more modern times, texts over the cellular network) are the most reliable way to get alarms out to field and on-call personal. Sure, someone could send a malicious fake page or text, but these alarms are mainly just heads-up to personal who are not in the operations center that something is amis. The main board will always be checked / personal will always call in and double check before anyone actually pushes any buttons.
This is a really stupid article.
-Matt
I have two major beefs with IPV6. The first is that the end-point 2^48 switch address space wasn't well thought-through. Hey, wouldn't it be great if we didn't have to use NAT and give all of those IOT devices their own IPV6 address? Well... no actually, NAT does a pretty good job of obscuring the internal topology of the end-point network. Just having a statefull firewall and no NAT exposes the internal topology. Not such a good idea.
The second is that all the discovery protocols were left unencrypted and made complex enough to virtually guarantee a plethora of possible exploits. Some have been discovered and fixed, I guarantee there are many more in the wings. IPV4 security is a well known problem with well known solutions. IPV6 security is a different beast entirely.
Other problems including the excessively flexible protocol layering allowing for all sorts of encapsulation tricks (some of which have already been demonstrated), pasting on a 'mandatory' IPSEC without integration with a mandatory secure validation framework (making it worthless w/regards to generic applications being able to assert a packet-level secure connection), assumptions that the address space would be too big to scan (yah right... the hackers didn't get that memo my tcpdump tells me), not making use of MAC-layer features that would have improved local LAN security, if only a little. Also idiotically and arbitrarily blocking off a switch subspace, eating 48 bits for no good reason and trying to disallow routing within that space (which will soon have to be changed considering that number of people who want to have stateful *routers* to break up their sub-48-bit traffic and who have no desire whatsoever to treat those 48 bits as one big switched sub-space).
The list goes on. But now we are saddled with this pile, so we have to deal with it.
-Matt
IPV6 actually makes things worse.
-Matt
There is no flood defense possible for most businesses at the tail-end of the pipe. When an attacker pushes a terrabit/s at you and at all the routers in the path leading to you as well as other leafs that terminate at those routers, from 3 million different IP addresses from compromised IOT devices, your internet pipes are dead, no matter how much redundancy you have.
Only the biggest companies out there can handle these kinds of attacks. The backbone providers have some defenses, but it isn't as simple as just blocking a few IPs.
-Matt
You just use the scroll-wheel. The scroll bar is always a last resort. I prefer the scroll-wheel myself, but if the system doesn't have a mouse -- that is, one only has the trackpad, then either two-finger scrolling (Apple style) or one-finger-right-side-of-pad scrolling is a pretty good substitute.
-Matt
The real problem is the touchpad hardware. The touchpad device itself may not be able to accurately track three or four fingers, and there isn't a thing the operating system can do to fix it. I've noticed this on chromebooks, in particular when I ported the touchpad driver for the Acer C720. The hardware gets very confused if you put more than two fingers down on the pad horizontally (or you cross them horizontally while you slide your fingers around).
It basically makes using more than two fingers very unreliable. My presumption is that a lot of laptops out there with these pads probably have the same hardware limitations.
-Matt
Unless the project has only one source file, compiling isn't really single-thread bound. Most projects can be built make -j N. When we do bulk builds, that's what we see happening most of the time so with very few exceptions your project builds should be able to make use of many cpu cores at once.
The few exceptions are: (1) The link phase is typically a choke point and serializes to one thread, and (2) Certain source files might be so large relative to the others that everything else finishes and the build is twiddling its thumbs waiting for that one 200,000 line source file to finish compiling before it can move on to the link phase.
One other note - Builds are like 99.9% cpu driven. Storage bandwidth is almost irrelevant because there is almost no I/O involved in doing a build vs the cpu time required. Source files are already likely cached in memory. Temporary files don't last long enough to even have a chance to get written to disk (if not using tmpfs), and object files and executables are tiny relative to available storage bandwidth and asynchronously flushed as well (so nobody has to wait on them to be flushed to disk).
So, for example, when we do a bulk build of all 24000+ applications in ports, we use tmpfs mounts for all temporary files and our disk I/O is almost non-existent throughout the process. The only time we see busy storage is during maximum peak load when the running compiler binaries exceed available ram and the system pages a bit (you have to allow this in order to optimize the non-peak portions of the build to ensure that all system resources are fully utilized throughout the entire 22-hour-long bulk build).
-Matt
Yes, but that is what the XPoint technology is trying to address. The NVMe technology is not designed to operate like ram and the latencies are still very high. Nominal NVMe latency for a random access is 15-30uS. The performance (1.5-3.0 GBytes/sec for normal and 5 GBytes/sec+ for high-end NVMe devices, reading) comes from the multi-queue design allowing many requests to be queued at the same time.
Very few workloads would be able to attain the required request concurrency to actually max-out a NVMe device. You have to have something like 64-128 random requests outstanding to max-out the bandwidth (fewer for sequential). Server-side services have no problem doing this, but very few consumer apps can take full advantage of it.
The NVMe design is thus more akin to being a fast storage controller and should not be considered similar to a dynamic ram controller in terms of performance capability.
Because of the request concurrency required to actually attain the high read capability of a NVMe device, people shouldn't throw away their SATA SSDs just yet. Most SATA SSDs will actually have higher write bandwidth than low-end NVMe devices (particularly small form factor NVMe devices). And for a lot of (particularly consumer) workloads, the NVMe SSD will not be a whole lot faster.
That said, I really love NVMe, particularly when configured as swap and/or a swap-based disk cache. And I love it even more as a primary filesystem. It's so fast that I've had to redesign numerous code paths in DragonFlyBSD to be able to take full advantage of it. For example, the buffer cache and VM page queue (pageout demon) code was never designed for a data read rate of 5 GBytes/sec. Think about what 5+ GBytes/sec of new file-backed VM pages being instantiated per second does to normal VM page queue algorithms which normally only keep a few hundred megabytes of completely free pages in PG_FREE. The pageout demon couldn't recycle pages fast enough to keep up!
Its a nice problem to have :-)
-Matt
I should add, the evidence of this is plentiful. Anyone remember the days of IDE PIO ? Before IDE DMA and in particular before command and data blocks could be fully buffered by a hardware FIFO in the control, IDE PIO was a complete disaster. It barely worked (and quite often didn't). And we had to pull out the stops as device driver writers to get it work as well as it did (which wasn't very well).
-Matt
Not quite true A.C. The instructions for those old 8-bit CPUs could be synchronized down to a single clock tick (basically crystal accuracy), thus allowing perfect read and write sampling of I/O directly. We could do direct synthesis and A/D sampling, for example, with no cycle error, as well as synchronize data streams and then burst data with no further handshaking. It is impossible to do that with a modern CPU, so anything which requires crystal-accurate output has to be offloaded to (typically an FPGA).
RTOSs only work up to a point, particularly because modern CPUs have supervisory interrupts (well, Intel at least has the SMI) which throw a wrench into the works. But also because it is literally impossible to count cycles for how long something will take. A modern RTOS works at a much higher level than the RTOSs and is unable to provide the same rock solid guarantees that the 8-bit RTOSs could.
-Matt
Looks interesting... I've pre-ordered two (both cpu models, 4G) for DragonFlyBSD, we'll get it working on them. Dunno about the SD card, but a PCIe SSD would certainly work. BIOS is usually the sticking point on these types of devices. Our graphics stack isn't quite up to Braswell yet but it might work in frame buffer mode (without accel). We'll see. The rest of it is all standard intel insofar as drivers are concerned.
My network dev says the Gigabit controller is crap :-) (he's very particular). But for a low-end device like this nobody will care.
All the rest of the I/O is basically just pinned out from the Intel cpu. Always fun to remark on specs, but these days specs are mostly just what the cpu chip/chipset supports directly.
I'm amused that some people in other comments are so indignant about the pricing. Back in the day, those of us who hacked on computers (Commodore, Atari, TRS-80, Apple-II, later the Amiga, etc) saved up and spent what would be equivalent to a few thousand dollars (in today's dollars) to purchase our boxes. These days enthusiast devices are *cheap* by comparison. My PET came with 16KB of ram and a tape cassette recorder for storage, and I later expanded it to 32KB and thought it was godly.
-Matt
Sure. Of course. This isn't news. And on top of that, most mobile users settle on just a few apps and use just those 90% of the time.
-Matt
What new and relevant thing do you want to see in the phone? I for one can't really think of anything. I don't really need a better camera, for example, nor do I need any on-phone storage. LTE (or LTE-A) is plenty fast enough, no point having more bandwidth that I'm not going to pay the cell carrier for. Wifi is plenty fast enough. Games run fine on the -6 so they'll run fine on the -7. What's left?
-Matt
Apple has lost an idiot as a customer? Probably not a big loss. Nobody is forcing you to buy a wireless handset and nothing is stopping you from trying out the adapter in an Apple Store to check the quality when it comes out.
-Matt
So full of complete nonsense. Throwing out terms without knowing what they actually mean, let alone whether an operating system actually has to make any changes to support it.
Take speed-shift for example... all it does is remove the need for the OS to calculate a P-state for HLT/MWAIT. All ACPI has to do is present a smaller list of P states and *ANY* OS that supports HLT/MWAIT p-state setting (which basically worked meaningfully from Haswell onward) will instantly be using SpeedShift. There's nothing to 'support' unless the OS is coded to intentionally break it.
AMD's SMT improvements don't need any OS-specific coding. The original bulldozer architecture *DID* need OS-specific coding, because it was a piece of shit (and a lot of us just didn't bother to code the OS to try to characterized mixed integer/FP loads), but continuing to use that coding in the newer architecture doesn't really cost anything. And, again, the CPU topology is made available to the OS via ACPI, and any OS since before Sandybridge could use it. Linux and the BSDs have been using the topology info provided by ACPI for years, and Microsoft had better have been too, so no specific OS coding is required.
What a load of crap.
-Matt
Firefox has been extremely unstable for us for at least the last year. Finally putting a process behind each tab is an important step, certainly, but its one they should have implemented 2+ years ago. I also really wish Mozilla would stop with all the useless bells and whistles that nobody uses and instead focus on stabilizing the code they have.
My recommendation... switch to chrome. It's a much better browser.
-Matt
Is ... can I run DragonFly on it? Or is the BIOS locked to Chrome ? If this baby has the normal write-protect screw / developer mode BIOS features that allow us to run whatever we want on it instead of being locked to chrome, then great!
We've had great success with the older Acer C720[P] (running a mobile haswell cpu) running DragonFly. So if one of these new HP Skylake-m babies allows me to cut into the dance then I'll give it a big thumbs up.
I'll have to buy one to find out, I guess.
-Matt
I will impart a warning here. I have a friend who has repeatedly tried to use non-Apple batteries in his Apple mobile devices and its been a dismal failure for him. Spend the money to have Apple replace your battery, you will be happier in the end.
Apple laptops... well, the ones with replaceable batteries are a different story. Going third-party there works fairly well. The ones that don't... again spend the money to have Apple do it for you, you will be happier in the end.
Another recommendation... when possible, always leave your devices plugged in. This causes the Apple battery management software to properly load cycle the full battery and will significantly increase battery life. I usually bring along an external battery and just keep my phone plugged in whenever possible for that very reason (when convenient).
My ipad-1's battery is still in great shape (now going on 6 years old), though the ipad-1 itself doesn't have enough memory to really be able to run much any more. My ipad-2 as well. 512M of ram isn't enough to run apps smoothly any more on the ipad-2 (and the ipad-1 can barely run anything), but the battery is in great shape because I leave the devices plugged in as much as possible.
-Matt
Perhaps not one key event, but a combination of solid state storage removing the hard-drive-failure event that often drove people to upgrade, CPU performance topping out, and RAM well beyond anything most programs need have all conspired together to give us desktops, laptops, and mobile devices that basically no longer get 'old'. Not to mention that power consumption is low enough now that PSUs just aren't burning out like they used to :-).
Something strange happened in the last year or two. I buy computers all the time for DragonFly testing, so I have a pile of machines of all different kinds including a bunch of BRIX form-factor units. I stuff nominal sweet-spot memory and storage into them all, always, because they get repurposed or farmed out to friends all the time to make room for new hw.
The strange thing that happened... it became convenient to just throw 8-16GB of ram into all of these things. Even the tiny little BRIX. And even the little BRIX can dual-head two 4K displays, and easily fit a 2.5" SSD (and so can hold quite a bit of storage). None of these boxes have any moving components except a fan or two. They don't fail if I put them on a shelf for a year.
Up until about 2 years ago I was regularly throwing away my oldest hardware, including the bulky cases (which had to be large enough to hold a CD and/or DVD and several 3.5" drives).
But the remainder of that really old hardware petered out last year. Now there's no reason at all to throw away my 'new' old hardware... it is still useful enough that I can give it away or repurpose some of its components. The cases are all small so I just reuse those if I can't find any use for the mobo. I reuse the SSDs (I never reused old hard drives). I reuse the PSUs (if any). There's no graphics card to replace since it is built into the cpu.
In fact, the only thing I haven't been able to recycle in the new old machines have been the DIMMs due to continuous technology changes, but those just stay with the original motherboard.
In our colocation for DragonFly our blade server (12 x haswell blades in 2U) has handled all of our needs and other than slowly replacing the remaining HDDs with SSDs will probably handle all of our needs for the next 10 years. Or longer. It will be interesting to see what the failure mode is for the hardware because it will probably be the first piece of hardware I own that stays fully active and relevant until the blades actually physically fail.
I love the technology but I think there's only more pain to come for Intel.
-Matt
Which is why I run the cable box into a dedicated ethernet port on the server and run a point-to-point VPN to a colo. Comcast aint gonna be snooping much :-) Nor will Verizon, since I drill an openvpn link to the colo from my phone as well.
-Matt
... is to disable all of its smarts. If you value your privacy, don't let it connect to the internet!
I'll take a regular 4K monitor without any bells and whistles thank you very much. And if it has a microphone or camera built into it that will be the first thing I stick my soldering iron into before I begin using it for real. Gouge out its eyes and ears, and we're good.
-Matt