Slashdot videos: Now with more Slashdot!

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.

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.

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.

The problem is cross vendor replication ends up taking the form of rdiff-backup or rsnapshot. Otherwise you end up with a single point of failure when your stupid NAS vendor pushes a firmware update that corrupts all your backups.

Yah, you are 100% right, to bad you don't work for the tape vendors.

The one little niggle, is that your numbers fail to account for the price of the library, which anyone writing more than one tape's worth of data is going to want really fast. Add in the price of a small/medium sized autoloader and it doubles the break even point.

Hence my own personal use of cloud backup technologies and small portable eSATA/USB raid arrays. Just don't drop them, and make sure to transport them in very well padded containers.

I use LTO3-6 all the time, they are pretty bullet proof. I can't remember the last time there was an actual hardware problem. All the tape problems I've had over the last few years have been PEBCAK, or should that be PEBCAL(ibrary).

LTO and modern tape aren't like the old ones (1990 and earlier) with dropped leaders, read errors, etc. Besides, running at many hundreds of MB/sec per drive, they have layers and layers of ECC, embedded servo tracks, etc ,etc. All the reliability engineering you expect from modern hardware. Also, while your vendors will cringe if you drop them on the floor, I've actually thrown them around, cracked the cases, etc and the data is still recoverable, heck fingerprints on the media are even tolerated.

Its just to bad that they are dragging their feet coming out with new generations cause its a fantastic way to take a snapshot, and bury it somewhere in case of disaster.

The T10kd which came out over a year ago, puts 8.5TB uncompressed on a tape (reusing the previous generation's media no less). So, basically the vendors are holding LTO back for unspecified reasons, probably in a vain attempt to recoup the last generations investment, or maybe to boost sales of their "enterprise" drives (T10kd, 3592).