Its probably takes all of a couple fields scattered around the database or a code to human description table somewhere.
Then when it comes to printing it, the result set gets joined to the human readable table and it gets printed as "code, human text".
Heck its hard to imagine that the table doesn't exist, which leaves you with the feeling that only printing the "codes" is on purpose.
Because, it keeps those pesky customers from asking why they paid $500 for something they can buy over the counter at walmart for $1, or why the chest xray cost $2000 when its the same as the one their doctor ordered which was only billed for $50.
But, that is what shared build machines are for. Not everyone is going to be building at once, and with a 5-20 member team its a lot less expensive to buy a machine with 40 cores and a bunch of midrange desktops/laptops, than buy all the developers high end workstations.
And, your sort of right the OS will do a certain amount of prefech/etc but that doesn't help when things are fragmented or the application/whatever is requesting things in a pattern that isn't easily predictable (say booting without a readyboot optimized system).
Try it out yourself, get the old sysinternals Disk Monitor and watch the size size attribute. Its in 512 byte sectors, and on my machine probably 1/3rd of the IO's are listed as "8". AKA 4k. Heck the example screenshot on the listed page is all 8 except for one 16.
So, yes small IO transfers are still an issue, and will be until we get OS's that can solve the hard problem of consolidating unpredictable IO streams. Heck a lot of people turn superfetch off because it slows things down. AKA aggressive prefetch isn't necessarily faster.
Gosh, stupid html tags ate most of my posting. Anyway here it is.
I don't understand why people still don't understand the difference between latency and bandwidth, and the fact that a huge amount of the desktop IO load is still less than 4k with a queue depth of basically 1.
If you look at many of the benchmarks you will notice that the.5-4k IO performance is pretty similar for all of these devices and that is with deep queues. Why is that? Because the queue depth and latency to complete a single command dictate the bandwidth. So you either need deeper queues or lower latency to go faster at those block sizes.
So the latency on PCIe is not that much better, but the queue depth can be much deeper than what is possible with a normal AHCI controller. This helps a lot with benchmarks, but not so much for a single user.
Anyway, boot times, and general single user performance is bottle necked mostly by latency. Especially when the throughput of larger transfers is greater than a few hundred MB/sec. So, the pieces large enough to take advantage of the higher bandwidth is a smaller (and growing smaller) portion of the pie.
Next time you start your favorite game look at the CPU/DISK IO. Its likely the game never gets anywhere close to the max IO performance of your disk, and if it does its only for a short period.
Anyway, its like multicore, beyond a fairly low core count most desktop type operations are better off with faster CPU's rather than more of them.
And just like desktop benchmarks, the guys running benchmarks seem lothe to heavily weigh single thread operations, or queue depth 1 1k IO loads in the overall performance picture even though its a large portion of actual system performance running everyday tasks.
I don't understand why people still don't understand the difference between latency and bandwidth, and the fact that a huge amount of the desktop IO load is still a few hundred MB/sec. So, the pieces large enough to take advantage of the higher bandwidth is a smaller (and growing smaller) portion of the pie.
Next time you start your favorite game look at the CPU/DISK IO. Its likely the game never gets anywhere close to the max IO performance of your disk, and if it does its only for a short period.
Anyway, its like multicore, beyond a fairly low core count most desktop type operations are better off with faster CPU's rather than more of them.
And just like desktop benchmarks, the guys running benchmarks seem lothe to heavily weigh single thread operations, or queue depth 1 1k IO loads in the overall performance picture even though its a large portion of actual system performance running everyday tasks.
You probably don't have to go that old, plenty of cars from the late 90's are both safer, and get better gas mileage. Sure they have ECU's too, but the ECU tends to be only for engine management, and its built with 80's era DIP's and 1Mhz processors. AKA you can reprogram it, repair it,etc.
I've have a late 90's Toyota, that is pretty open (or has been reverse engineered) has airbags/etc. But it doesn't have TPS's that have to be replaced all the time, or an AC that decides I don't want recirculation on with the defroster, or a headlamp controller that is part of the ECU and won't allow me to have the car running with the headlights off. Its stereo is also standalone... Etc. All things the more recent toyota I also own has, and its a PITA.
Basically, there is nothing scary about late 80's-90's cars with ECU's when the ECU's did little more than timing advance and injector timing (no ABS). You could probably build a replacement for those functions using an arduino and a couple weekends on a dynamo.
The problem is the modern, computer on wheels vehicles where everything is integrated into a network and your car refuses to start when it notices the gas cap hasn't been screwed in completely.
You mention intel, but fail to acknowledge that they are probably the best bet on linux right now. Their drivers are open, and seem to actually work pretty good (in my fairly limited experience). I've even played a number of humble bundle games on my intel based laptop.
Maybe the performance isn't good, but at least they work enough to get X running across a couple screens without crashing/studdering/etc like the open source AMD/Nvidia drivers, or simply refusing to work (as the nvidia proprietary drivers have done for me a couple times).
The biggest secret to having good people isn't hiring H1B's it's working to retain the people you have.
But... This would imply that people aren't "human resources" that can be swapped with each other at will. It implies that someone who works on a project for a few years can contribute more meaningfully to a product than someone just hired.
I've seen this a few times in my career, an "average" developer with a few years experience on a project may not be as celebrated as the rock star that was just hired, but a couple years down the line when the rock star has moved on, its the "average" developer's code that doesn't need weekly maintenance. Its, often the guys that have been there for a couple years tasked with cleaning up the mess. A problem, much harder than creating it in the first place. That is if they are still around, because even an average developer can put their resume out there and get a pay bump if they put the effort into it.
Bottom line, I totally agree, retention of good solid "average" developers is what companies should be focusing on. Everyone is looking for a magic solution, but in reality a lot of software development is just slogging through loads and loads of unstimulating work.
I have the edgerouter POE, which is a fantastic piece of hardware, but it still doesn't support proper vlan tagging controls on the embedded switch ports. A feature I would add myself but the hardware isn't open enough to do it without a lot of reverse engineering.
So, this makes me wonder if they are sort of stuck between stupid hardware companies and the GPL. They may not be able to publish changes to the open source products without violating their NDAs with the manufactures of assorted chips/etc they use.
I'm not trying to defend them, just point out a situation I've found myself in. GPL software is great for bootstraping a project, but for some of these platforms it can be a real PITA. I feel for small companies like Ubiquiti. But I'm pretty irritated by Sony, broadcom, cisco, etc which are also playing the same game.
I already have >1G of ram on my video card. And besides, that means that we might be catching up proportionally to the early 90's when I had a 4MB computer with a 1MB graphics card.
Bring it on, I for one welcome having a 50+" display that I can't see the pixels on from 2' away. Even if the video card burns up 200W just to refresh a 2d screen. That is why I have a desktop. Leave the boys with their laptops to crummy resolutions.
Without knowing the size of the display the whole discussion is pointless 8k in 2" or 8k in 50"?
Cause there is a world of difference, and humans have pretty good spatial memory. Having a monitor larger than what can be seen without moving your eyes/head is a good thing. In fact that is what I'm using right now, 4 monitors are already more than I can see at the same time. With my focus on the left monitor I can't really see anything in the right. But that doesn't make it less useful for having a PDF open, or another window of code. I can flip my eyes back and forth between the right and the left far faster (and less disruptively) than I can swap virtual desktops.
I disagree, speaking as someone who has in fact had a weeks long job running on my desktop before. I mean if you have a fast PC (desktop processors are often faster per core, at the expense of fewer cores)
Well you have to differentiate whether your talking about an intel desktop machine or a "workstation" class machine. The difference at this point is the "workstation" is using xeon class processors, and has ECC. The problem is that the "workstation" has exactly the same processors as the rack mount machine running in the server room with a much better power and cooling environment.
That said, it is possible to get something like the Xeon E5-2637 v3 which is a quad core, 3.5 Ghz (+turbo) CPU. Sure its not the the 4+Ghz you can get on a "desktop" CPU but it does have a LGA 2011v3 which will give you significantly more memory bandwidth and ECC.
Frankly, while I think running anything besides a desktop workload on a "desktop" is silly because those kinds of workloads tend to be better handed with servers. It does seem that intel has lost its way a little when it comes to extreme single threaded performance. Particularly in the server space. Why they don't offer a 200+ watt pig clocked a few percent higher seems strange. Pretty much everyone else does it (POWER8, z13 (@ 5.2 Ghz), AMD, etc).
Unless the virus is resident in Bios... before booting into your OS.
Well, for this to work, you had better have jumpers on all your PCI/thunderbolt/etc devices with option ROMs as well. Otherwise your BIOS is going to get owned during POST.
But, all that was a fine plan before we got EFI stuffed down our throats. Now you better make sure to unplug whatever device holds the EFI System Partition as well. Because you may be loading EFI "drivers"/etc from there.
But there is a gocha there too, because lots of machines now have the primary storage soldered to the mainboard...
X86 was a poor ISA when the first 8086 chips were made (but good, given hardware capabilities at the time). That was about 40 years ago. MIPS and Sparc (and ARM) are all better than x86.
You, speak like its 1995 before anyone fully understood OoO, or started decoupling the micro ISA from the actual ISA. The core x86 arch (ignore the 286/386 protected mode instructions which are very complex, and mostly unused) turns out to be fairly simple when compared with mips/sparc/arm. Three architectures that all made small, but hard to overcome decisions for creating large superscalar renamed OoO CPU's. Take for example the fact that traditionally all of ARM's instructions can be conditionally executed. This complicates long pipelines, especially when they are OoO because now you have to resolve an additional dependency for every instruction before its retired. If you look at the optimization guides for cortex you will see that the basic ideas of ARM had to be "evolved" a little in order to make it fast. Similarly register windows (SPARC), multiple load/store instructions (more complex exception mechanism), etc etc etc..
So, to say that x86 is somehow "worse" or that any of those named architectures is "better" evokes the very wrong headed RISC vs CISC stupidity of the 1990s. This has been known for nearly a decade by anyone close to the development of any actual CPUs. Similar to the discussion ten years ago on how x86 could never be power competitive with ARM because there was some "fundamental" problem with the ISA.
ISA's are now "good" when they remain flexible enough to deal with multiple different micro architectural implementations without providing handicaps that limit the designs. Turns out that x86 isn't that bad, it seems to be a bit of luck that the src/dest register model can be renamed easily, and that it has some higher level instructions (like rep movsd) that can be optimized really well in microcode.
I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language here but this post would be TL;DR; for most people. Lets just settle for goggling "javascript terrible" and reading the first couple links.
The fact that there are actually people who think using in on the server is a good idea, proves there are insane or completely incompetent developers out there. If someone actually approaches me with this idea, I immediately think they are an idiot.
See, on the browser we basically have to deal with javascript because there aren't any real alternatives. But things that are just "issues" or "irritations" in the browser quickly blossom into product killing problems when used on the server.
Oh, and yes, I've written my fair share of javascript (and other languages), so don't think i'm talking out of my ass here.
already had their sensation reduced by half via infant genital cutting.
Which is yet another case of the double standard. Trim a woman, get on the news for genital mutilation, go to jail.
Mutilate a male baby, get paid by insurance for it.
Not, only that but IIRC in the state I live in, the decision is the mother's, not the father's if there is a conflict.
Personally, I think it should be illegal to perform it on anyone less than 18 years of age. My parents religious / whatever hangups should not be affecting my life 40 years later.
but that it provides nothing of value to offset the cost of maintaining a separate toolchain, training programmers, building libraries, etc.
That is why there is rust, go and a dozen other languages trying to replace C or C++.
I sort of like C++, that said, I think object pascal is a much better language, it fixes a lot of the core problems with C (can you say embedded string length? There goes 1/2 of the buffer overflow problems that have happened over the last 20 years) while maintaining the ability to optimize nearly as well. Pascal is actually faster than the vast majority of "C" replacements people are using today.
just because of all the extra typing, and the reduced readability:
If typing "begin" and "end" instead of "{" and "}" were a big problem I would claim you need a better editor. That said the speed of code generation is just about never an issue in any language because thinking about the problem or debugging the code is a much larger time sink. Finally, I would claim that pascal is light years ahead of C++ and even C due to the restricted syntax. Did you forgot about the IOCC? Because getting to those levels of obfuscation is going to be a lot harder in pascal.
Long term, with filesystem level deduplication becoming more common, I wonder if the best thing would be to move back to statically linked executables.
Especially on windows with WinSxS basically duplicating every shared object in the system. The point of shared libraries was to reduce the application footprint, but MS decided it was more important to maintain every single version of every single shared library being used rather than allow them to collapse together in the oft chance that it caused some application defect.
Since every single application it seems, manages to find their own version of any given DLL its pretty rare for any sharing to actually take place. Might just as well statically link the whole darn thing.
Let me tell you about mine. I have an 8 year old "workstation" class machine that is basically a dumb terminal running web browser, editor, xserver and a couple other things. It has 4 monitors raised to eye level, and a keyboard that is probably larger than your laptop. The whole setup spans the corner of my desk where I sit in a really comfortable chair, leaned back slightly.
About 50' away, through two doors is a room that sounds like a jet engine lab full of modern servers and disks in racks.
All the data is stored on a network attached server with SAN attached IO. It takes regular automatic snapshots of everything in mine and my co workers "home directories" and rolls them regularly to tape on a daily basis.
When I need to build some code, I hit a key in my editor and it tells an enormous build box (with multiple GB/sec of IO to the disk storage system) in the lab to spin up a shit ton of CPU's and built my code. When its done, I run it on another cluster of machines.
When I leave work, I carry a light weight laptop (sometimes just an ipad) and use RDP to connect to the workstation at my desk. In the rare case that I don't have internet access, I can usually find some documentation or other "lightweight" laptop appropriate work to do that doesn't require a connection to more hardware than you will ever be able to carry in your backpack.
As others have said, you might consider analyzing your workflow.
Interstellar travel would require unimaginable breakthroughs in propulsion. Even sending an unmanned probe, capable of slowing down to orbit another star, and then communicating over the enormous distance back to Earth is totally impossible with current technology.
By "current technology" you mean the lame chemical rockets we have been using for nearly a century? How about we step into the 1960's and actually build one of the proposed project Orion vehicles?. Something like that could actually reach another star within my children's lifetime, especially if it was only designed as a flyby rather than stopping in system.
Furthermore, Nuclear thermal rockets provide approximately twice (depending on design) the ISP as conventional rockets, and are just as clean and possibly easier to build if the working fluid is carefully chosen. Frankly I'm a little surprised that space-x hasn't announced some designs, they aren't limited by the stupidity of the anti nuke crowd.
Finally, the real breakthrough that would make human travel interstellar travel possible is actual cryogenic suspension. Which is quite possible, I just don't expect to see it in my lifetime due to the complete lack of funding for that kind of research. Most of the funding that goes in that direction is narrowly focused on prolonging organs outside of the body, or allowing extended surgical procedures. Frankly, this is one area where appropriate funding might be able to create a major scientific expansion of our understanding of biology, and economic benefits to go along with it.
So, no, interstellar travel is not at the level of new physics, just a willingness to focus on the problem and solve the remaining issues.
Using an IOMMU gives such devices direct virtual memory access which it fully safe (compared to physical memory access which is not safe and what apple did here).
I was going to mention IOMMUs, but I thought it would just confuse the issue (see the host controller confusion on my other comment).
In this case IOMMUs will only help you a little, as the article mentions that the option roms are being executed. Executing in the early boot environment, without a hypervisor, or in the hypervisor context, means that the option rom code can simply set the IOMMU to map to any memory the device wishes to access.
I'm pretty sure in the case of USB 3 that DMA is a function of the host controller. A device by itself cannot inject into arbitrary memory. This thunderbolt "vulnerability" is the equivalent of the windows autorun on insertion function that was disabled years ago. Only this functions above the level of the current user (aka much worse).
It may not seem like a big deal, but things like this are used more and more to justify land closures.
Well, just about anything justifies a land closure now. The balcones canyonlands was created for the express purpose of preservation and recreation which didn't infringe on the preservation goals. Yet, it has _NEVER_ been open for recreation even though the two species its intended to preserve are _MIGRATORY_ and only spend a few months a year in the preserve. The place is surrounded by fences and no trespassing signs, and the web page talks about the recreation opportunities, and then lists all _SEVEN_ miles of trails in 23,000 acres of preserve. There is actually something like 10x as many miles of public roads running through it.
Worse yet, a lot (possibly most) of the studies seem to suggest that human presence (in the form of hiking and biking trails) actually helps the birds because it scares their main predators away.
Slashdot Mirror
Its probably takes all of a couple fields scattered around the database or a code to human description table somewhere.
Then when it comes to printing it, the result set gets joined to the human readable table and it gets printed as "code, human text".
Heck its hard to imagine that the table doesn't exist, which leaves you with the feeling that only printing the "codes" is on purpose.
Because, it keeps those pesky customers from asking why they paid $500 for something they can buy over the counter at walmart for $1, or why the chest xray cost $2000 when its the same as the one their doctor ordered which was only billed for $50.
But, that is what shared build machines are for. Not everyone is going to be building at once, and with a 5-20 member team its a lot less expensive to buy a machine with 40 cores and a bunch of midrange desktops/laptops, than buy all the developers high end workstations.
It only takes a queue depth of 2 or 3 for maximum linear throughput.
I haven't any idea why you are so up voted, because your flat out wrong, 5 minutes with a benchmark like ATTO allows you to see the performance with small sequential IO and queue depth. Another benchmark showing ATTO sequential IO's for small transfers
And, your sort of right the OS will do a certain amount of prefech/etc but that doesn't help when things are fragmented or the application/whatever is requesting things in a pattern that isn't easily predictable (say booting without a readyboot optimized system).
Try it out yourself, get the old sysinternals Disk Monitor and watch the size size attribute. Its in 512 byte sectors, and on my machine probably 1/3rd of the IO's are listed as "8". AKA 4k. Heck the example screenshot on the listed page is all 8 except for one 16.
So, yes small IO transfers are still an issue, and will be until we get OS's that can solve the hard problem of consolidating unpredictable IO streams. Heck a lot of people turn superfetch off because it slows things down. AKA aggressive prefetch isn't necessarily faster.
Gosh, stupid html tags ate most of my posting. Anyway here it is.
I don't understand why people still don't understand the difference between latency and bandwidth, and the fact that a huge amount of the desktop IO load is still less than 4k with a queue depth of basically 1.
If you look at many of the benchmarks you will notice that the .5-4k IO performance is pretty similar for all of these devices and that is with deep queues. Why is that? Because the queue depth and latency to complete a single command dictate the bandwidth. So you either need deeper queues or lower latency to go faster at those block sizes.
So the latency on PCIe is not that much better, but the queue depth can be much deeper than what is possible with a normal AHCI controller. This helps a lot with benchmarks, but not so much for a single user.
Anyway, boot times, and general single user performance is bottle necked mostly by latency. Especially when the throughput of larger transfers is greater than a few hundred MB/sec. So, the pieces large enough to take advantage of the higher bandwidth is a smaller (and growing smaller) portion of the pie.
Next time you start your favorite game look at the CPU/DISK IO. Its likely the game never gets anywhere close to the max IO performance of your disk, and if it does its only for a short period.
Anyway, its like multicore, beyond a fairly low core count most desktop type operations are better off with faster CPU's rather than more of them.
And just like desktop benchmarks, the guys running benchmarks seem lothe to heavily weigh single thread operations, or queue depth 1 1k IO loads in the overall performance picture even though its a large portion of actual system performance running everyday tasks.
I don't understand why people still don't understand the difference between latency and bandwidth, and the fact that a huge amount of the desktop IO load is still a few hundred MB/sec. So, the pieces large enough to take advantage of the higher bandwidth is a smaller (and growing smaller) portion of the pie.
Next time you start your favorite game look at the CPU/DISK IO. Its likely the game never gets anywhere close to the max IO performance of your disk, and if it does its only for a short period.
Anyway, its like multicore, beyond a fairly low core count most desktop type operations are better off with faster CPU's rather than more of them.
And just like desktop benchmarks, the guys running benchmarks seem lothe to heavily weigh single thread operations, or queue depth 1 1k IO loads in the overall performance picture even though its a large portion of actual system performance running everyday tasks.
You probably don't have to go that old, plenty of cars from the late 90's are both safer, and get better gas mileage. Sure they have ECU's too, but the ECU tends to be only for engine management, and its built with 80's era DIP's and 1Mhz processors. AKA you can reprogram it, repair it,etc.
I've have a late 90's Toyota, that is pretty open (or has been reverse engineered) has airbags/etc. But it doesn't have TPS's that have to be replaced all the time, or an AC that decides I don't want recirculation on with the defroster, or a headlamp controller that is part of the ECU and won't allow me to have the car running with the headlights off. Its stereo is also standalone... Etc. All things the more recent toyota I also own has, and its a PITA.
Basically, there is nothing scary about late 80's-90's cars with ECU's when the ECU's did little more than timing advance and injector timing (no ABS). You could probably build a replacement for those functions using an arduino and a couple weekends on a dynamo.
The problem is the modern, computer on wheels vehicles where everything is integrated into a network and your car refuses to start when it notices the gas cap hasn't been screwed in completely.
You mention intel, but fail to acknowledge that they are probably the best bet on linux right now. Their drivers are open, and seem to actually work pretty good (in my fairly limited experience). I've even played a number of humble bundle games on my intel based laptop.
Maybe the performance isn't good, but at least they work enough to get X running across a couple screens without crashing/studdering/etc like the open source AMD/Nvidia drivers, or simply refusing to work (as the nvidia proprietary drivers have done for me a couple times).
The biggest secret to having good people isn't hiring H1B's it's working to retain the people you have.
But... This would imply that people aren't "human resources" that can be swapped with each other at will. It implies that someone who works on a project for a few years can contribute more meaningfully to a product than someone just hired.
I've seen this a few times in my career, an "average" developer with a few years experience on a project may not be as celebrated as the rock star that was just hired, but a couple years down the line when the rock star has moved on, its the "average" developer's code that doesn't need weekly maintenance. Its, often the guys that have been there for a couple years tasked with cleaning up the mess. A problem, much harder than creating it in the first place. That is if they are still around, because even an average developer can put their resume out there and get a pay bump if they put the effort into it.
Bottom line, I totally agree, retention of good solid "average" developers is what companies should be focusing on. Everyone is looking for a magic solution, but in reality a lot of software development is just slogging through loads and loads of unstimulating work.
I have the edgerouter POE, which is a fantastic piece of hardware, but it still doesn't support proper vlan tagging controls on the embedded switch ports. A feature I would add myself but the hardware isn't open enough to do it without a lot of reverse engineering.
So, this makes me wonder if they are sort of stuck between stupid hardware companies and the GPL. They may not be able to publish changes to the open source products without violating their NDAs with the manufactures of assorted chips/etc they use.
I'm not trying to defend them, just point out a situation I've found myself in. GPL software is great for bootstraping a project, but for some of these platforms it can be a real PITA. I feel for small companies like Ubiquiti. But I'm pretty irritated by Sony, broadcom, cisco, etc which are also playing the same game.
I already have >1G of ram on my video card. And besides, that means that we might be catching up proportionally to the early 90's when I had a 4MB computer with a 1MB graphics card.
Bring it on, I for one welcome having a 50+" display that I can't see the pixels on from 2' away. Even if the video card burns up 200W just to refresh a 2d screen. That is why I have a desktop. Leave the boys with their laptops to crummy resolutions.
About time.
Without knowing the size of the display the whole discussion is pointless 8k in 2" or 8k in 50"?
Cause there is a world of difference, and humans have pretty good spatial memory. Having a monitor larger than what can be seen without moving your eyes/head is a good thing. In fact that is what I'm using right now, 4 monitors are already more than I can see at the same time. With my focus on the left monitor I can't really see anything in the right. But that doesn't make it less useful for having a PDF open, or another window of code. I can flip my eyes back and forth between the right and the left far faster (and less disruptively) than I can swap virtual desktops.
I disagree, speaking as someone who has in fact had a weeks long job running on my desktop before. I mean if you have a fast PC (desktop processors are often faster per core, at the expense of fewer cores)
Well you have to differentiate whether your talking about an intel desktop machine or a "workstation" class machine. The difference at this point is the "workstation" is using xeon class processors, and has ECC. The problem is that the "workstation" has exactly the same processors as the rack mount machine running in the server room with a much better power and cooling environment.
That said, it is possible to get something like the Xeon E5-2637 v3 which is a quad core, 3.5 Ghz (+turbo) CPU. Sure its not the the 4+Ghz you can get on a "desktop" CPU but it does have a LGA 2011v3 which will give you significantly more memory bandwidth and ECC.
Frankly, while I think running anything besides a desktop workload on a "desktop" is silly because those kinds of workloads tend to be better handed with servers. It does seem that intel has lost its way a little when it comes to extreme single threaded performance. Particularly in the server space. Why they don't offer a 200+ watt pig clocked a few percent higher seems strange. Pretty much everyone else does it (POWER8, z13 (@ 5.2 Ghz), AMD, etc).
I saw korn back in 98 and bought a korn bottle opening at the show. I went back to see them again in 99, the bottle opener was on my keychain.
Did you actually think the security at a concert is there to protect the concert attendees?
Eye rolling... Their primary job is to protect the revenue streams inside the concert. Hence the focus on busting people with hip flasks and the like.
Unless the virus is resident in Bios... before booting into your OS.
Well, for this to work, you had better have jumpers on all your PCI/thunderbolt/etc devices with option ROMs as well. Otherwise your BIOS is going to get owned during POST.
But, all that was a fine plan before we got EFI stuffed down our throats. Now you better make sure to unplug whatever device holds the EFI System Partition as well. Because you may be loading EFI "drivers"/etc from there.
But there is a gocha there too, because lots of machines now have the primary storage soldered to the mainboard...
When I think of Unions I think of all the corrupt Unions that litter the USA.
Union "corruption" in the US is a joke/talking point to distract people from the "corruption" of the oligarchs.
X86 was a poor ISA when the first 8086 chips were made (but good, given hardware capabilities at the time). That was about 40 years ago. MIPS and Sparc (and ARM) are all better than x86.
You, speak like its 1995 before anyone fully understood OoO, or started decoupling the micro ISA from the actual ISA. The core x86 arch (ignore the 286/386 protected mode instructions which are very complex, and mostly unused) turns out to be fairly simple when compared with mips/sparc/arm. Three architectures that all made small, but hard to overcome decisions for creating large superscalar renamed OoO CPU's. Take for example the fact that traditionally all of ARM's instructions can be conditionally executed. This complicates long pipelines, especially when they are OoO because now you have to resolve an additional dependency for every instruction before its retired. If you look at the optimization guides for cortex you will see that the basic ideas of ARM had to be "evolved" a little in order to make it fast.
Similarly register windows (SPARC), multiple load/store instructions (more complex exception mechanism), etc etc etc..
So, to say that x86 is somehow "worse" or that any of those named architectures is "better" evokes the very wrong headed RISC vs CISC stupidity of the 1990s. This has been known for nearly a decade by anyone close to the development of any actual CPUs. Similar to the discussion ten years ago on how x86 could never be power competitive with ARM because there was some "fundamental" problem with the ISA.
ISA's are now "good" when they remain flexible enough to deal with multiple different micro architectural implementations without providing handicaps that limit the designs. Turns out that x86 isn't that bad, it seems to be a bit of luck that the src/dest register model can be renamed easily, and that it has some higher level instructions (like rep movsd) that can be optimized really well in microcode.
I could go into a dozen technical reasons why javascript is a terrible, horrible, outrageously bad language here but this post would be TL;DR; for most people. Lets just settle for goggling "javascript terrible" and reading the first couple links.
Or for some silly (not not really deal killing) things watch https://www.destroyallsoftware...
The fact that there are actually people who think using in on the server is a good idea, proves there are insane or completely incompetent developers out there. If someone actually approaches me with this idea, I immediately think they are an idiot.
See, on the browser we basically have to deal with javascript because there aren't any real alternatives. But things that are just "issues" or "irritations" in the browser quickly blossom into product killing problems when used on the server.
Oh, and yes, I've written my fair share of javascript (and other languages), so don't think i'm talking out of my ass here.
already had their sensation reduced by half via infant genital cutting.
Which is yet another case of the double standard. Trim a woman, get on the news for genital mutilation, go to jail.
Mutilate a male baby, get paid by insurance for it.
Not, only that but IIRC in the state I live in, the decision is the mother's, not the father's if there is a conflict.
Personally, I think it should be illegal to perform it on anyone less than 18 years of age. My parents religious / whatever hangups should not be affecting my life 40 years later.
but that it provides nothing of value to offset the cost of maintaining a separate toolchain, training programmers, building libraries, etc.
That is why there is rust, go and a dozen other languages trying to replace C or C++.
I sort of like C++, that said, I think object pascal is a much better language, it fixes a lot of the core problems with C (can you say embedded string length? There goes 1/2 of the buffer overflow problems that have happened over the last 20 years) while maintaining the ability to optimize nearly as well. Pascal is actually faster than the vast majority of "C" replacements people are using today.
just because of all the extra typing, and the reduced readability:
If typing "begin" and "end" instead of "{" and "}" were a big problem I would claim you need a better editor. That said the speed of code generation is just about never an issue in any language because thinking about the problem or debugging the code is a much larger time sink. Finally, I would claim that pascal is light years ahead of C++ and even C due to the restricted syntax. Did you forgot about the IOCC? Because getting to those levels of obfuscation is going to be a lot harder in pascal.
Long term, with filesystem level deduplication becoming more common, I wonder if the best thing would be to move back to statically linked executables.
Especially on windows with WinSxS basically duplicating every shared object in the system. The point of shared libraries was to reduce the application footprint, but MS decided it was more important to maintain every single version of every single shared library being used rather than allow them to collapse together in the oft chance that it caused some application defect.
Since every single application it seems, manages to find their own version of any given DLL its pretty rare for any sharing to actually take place. Might just as well statically link the whole darn thing.
Let me tell you about mine. I have an 8 year old "workstation" class machine that is basically a dumb terminal running web browser, editor, xserver and a couple other things. It has 4 monitors raised to eye level, and a keyboard that is probably larger than your laptop. The whole setup spans the corner of my desk where I sit in a really comfortable chair, leaned back slightly.
About 50' away, through two doors is a room that sounds like a jet engine lab full of modern servers and disks in racks.
All the data is stored on a network attached server with SAN attached IO. It takes regular automatic snapshots of everything in mine and my co workers "home directories" and rolls them regularly to tape on a daily basis.
When I need to build some code, I hit a key in my editor and it tells an enormous build box (with multiple GB/sec of IO to the disk storage system) in the lab to spin up a shit ton of CPU's and built my code. When its done, I run it on another cluster of machines.
When I leave work, I carry a light weight laptop (sometimes just an ipad) and use RDP to connect to the workstation at my desk. In the rare case that I don't have internet access, I can usually find some documentation or other "lightweight" laptop appropriate work to do that doesn't require a connection to more hardware than you will ever be able to carry in your backpack.
As others have said, you might consider analyzing your workflow.
Interstellar travel would require unimaginable breakthroughs in propulsion. Even sending an unmanned probe, capable of slowing down to orbit another star, and then communicating over the enormous distance back to Earth is totally impossible with current technology.
By "current technology" you mean the lame chemical rockets we have been using for nearly a century? How about we step into the 1960's and actually build one of the proposed project Orion vehicles?. Something like that could actually reach another star within my children's lifetime, especially if it was only designed as a flyby rather than stopping in system.
Furthermore, Nuclear thermal rockets provide approximately twice (depending on design) the ISP as conventional rockets, and are just as clean and possibly easier to build if the working fluid is carefully chosen. Frankly I'm a little surprised that space-x hasn't announced some designs, they aren't limited by the stupidity of the anti nuke crowd.
Finally, the real breakthrough that would make human travel interstellar travel possible is actual cryogenic suspension. Which is quite possible, I just don't expect to see it in my lifetime due to the complete lack of funding for that kind of research. Most of the funding that goes in that direction is narrowly focused on prolonging organs outside of the body, or allowing extended surgical procedures. Frankly, this is one area where appropriate funding might be able to create a major scientific expansion of our understanding of biology, and economic benefits to go along with it.
So, no, interstellar travel is not at the level of new physics, just a willingness to focus on the problem and solve the remaining issues.
Using an IOMMU gives such devices direct virtual memory access which it fully safe (compared to physical memory access which is not safe and what apple did here).
I was going to mention IOMMUs, but I thought it would just confuse the issue (see the host controller confusion on my other comment).
In this case IOMMUs will only help you a little, as the article mentions that the option roms are being executed. Executing in the early boot environment, without a hypervisor, or in the hypervisor context, means that the option rom code can simply set the IOMMU to map to any memory the device wishes to access.
I'm pretty sure in the case of USB 3 that DMA is a function of the host controller. A device by itself cannot inject into arbitrary memory. This thunderbolt "vulnerability" is the equivalent of the windows autorun on insertion function that was disabled years ago. Only this functions above the level of the current user (aka much worse).
It may not seem like a big deal, but things like this are used more and more to justify land closures.
Well, just about anything justifies a land closure now. The balcones canyonlands was created for the express purpose of preservation and recreation which didn't infringe on the preservation goals. Yet, it has _NEVER_ been open for recreation even though the two species its intended to preserve are _MIGRATORY_ and only spend a few months a year in the preserve. The place is surrounded by fences and no trespassing signs, and the web page talks about the recreation opportunities, and then lists all _SEVEN_ miles of trails in 23,000 acres of preserve. There is actually something like 10x as many miles of public roads running through it.
Worse yet, a lot (possibly most) of the studies seem to suggest that human presence (in the form of hiking and biking trails) actually helps the birds because it scares their main predators away.