Triples can have their own fun failure modes. Suppose a surge or the like fries two chips at once. It's rather rare, but it happens from time to time. The instructions come out and now you have three chips with different results. Which ones are bad and which ones are the good? More importantly, how do you recover without taking the entire system down. Redundancy in this way means you have the best chance of catching problems, and also recovering from those problems when things do go cactus.
No. The DOJ has standardized on Courier for a font, and Courier's a built in font on pretty much all decent word processing programs and printers. The State Department used to use it too, but switched to Times New Roman some years ago.
The BSDs have far less lock-in with the default components than Linux distributions usually do. For example, I dislike the default syslog daemon, so, I disabled the default, and used my own. This involved adding two lines to /etc/rc.conf --
syslog_ng_enable="YES"
syslogd_enable="NO"
and that was it. Unlike systemd's way of doing it, the default syslog facility isn't started at all, doesn't run, period. Pretty much all the other low level services -- crond, dhcpd, ntpd, etc -- are the same way. This is one of the many failings as to how systemd operates. One should have reasonable defaults, but at the same time, if the defaults don't work, it should be easy to change them.
FreeBSD, OpenBSD, NetBSD, Illumos, etc. Chances are, you don't even need to tie yourself to the Linux kernel. Lots of OSes out there that don't inflict their users with systemd.
It's functional. It has all the components needed to code in a functional style, but at the same time, lets you use other paradigms, such as OO, when they make the most sense to do so.
I'd argue a "pure" functional language is akin to trying to write a novel on a keyboard without an "e" key. Sure, you'll eventually stumble and write "Gadsby", but there are times when being able to cheat is useful in making your code more clear and concise. When I code stuff in C++ or C#, I keep my objects immutable most of the time because it's the easiest way to rationalize the various components that way, but at the same time, when I'm doing things like handling I/O, a pure functional style gets in the way.
The 8051 family also has a huge amount of support tooling for it -- compilers, validation tooling, etc. For a lot of jobs where the 8051 lives, a new architecture would just mean an expensive set of validation tests for no real benefit.
Their "revolution" is using federated logins and an integrated pay service. So a google account or the like and google pay. About the only interesting take home here is that developers would do well to keep their app sizes down and to design for their market. Everything else, you can get from android and from ios today.
Yes, you could, but then you run into the potential problem where dependency A uses version 0.6.x, but dependency B starts using 0.7.x, because there's no stability. It becomes an increasing maintenance nightmare, where every dependency adds new potential headaches because no one's willing to create a version that's supported for more than a few months. Async I/O is as bad as he paints it because every component that you can use isn't stable and has no plans toward stability.
You're fighting the wrong battle here in order to get people to use better tools. Most people don't care if it's Free Software or not. They want something that's simple to use, and offers reasonable security. Right now, XMPP is not, due to the awful clients out there, and the attitudes towards any sort of comparisons with products that they are less philosophically aligned to.
This is perhaps the biggest problem Free Software programs have when you start treading away from things like a browser. There is a huge hostility to ease of use and building things that are Powerful Enough. People don't care if you have a lisp scripting language embedded in your app, they care about how long it takes to get started doing the stuff they care about with your software. Until usability becomes more important, then XMPP isn't going to gain traction.
The Pi has a single USB OTG interface, and no onboard ethernet. On the regular Pis, that's sent to an on-board hub, which fans it out to the USB sockets and the USB-Ethernet chips. The Compute Module, on the other hand, doesn't include a hub and Ethernet chip, because not every application will need it, and probably more importantly, it can be set to boot off code it receives from a USB host. This is useful in debugging because you can start working on things with a very minimal number of connections, and also so you can rapidly reprogram it without having to reflash for every boot.
In general, the CM has a lot of support for I/O that is just not feasible with the package the regular PI uses. Things like the extra camera and display ports can be useful for computer vision packages, but would make routing on the normal board real difficult. By minimizing the extent of the breakout, they really do make the chip able to be considered in a lot more use cases.
Dedicated hardware would be much, much faster than an app, and would give much more guarantees about real time performance. There are a growing number of FPGAs and ASICs being used in AI research because they can be intimately tuned for the task at hand.
Why is it so hard to just say, "precompile your code?" Just in time means having to take the same code, and do the same transformations to it, parse and reparse the code, every time you start the app. Yes, React may be a nice templating engine, but why make everyone go through the same process over and over again when you can copy once and not have to worry about it anymore?
Smart rendering would involve using a mostly static template that's updated with the relatively few dynamic elements as the page is being readied to be sent over the wire. If 90% of your dynamic content is the same, why put that through your app processes at all?
Less complexity, I imagine. If you've already got a beefy MySQL setup, then maintaining a separate Redis setup will introduce quite a bit of redundancy and chances for failure. Given that the big SQL databases have key value engines these days, you're going to get decent performance out of them as well.
There are a lot of parts of ops that handle things that aren't easily scriptable. What do usage patterns look like so you can better manage when to bring servers up/down to handle normal usage flow and have servers warmed up when they're needed? Are you using the best build options for your VMs? Are you using the best VMs for your application? Are you at the best datacenter for your application? Even with certain build options having better automation tools than before, there are still a lot of places where it the world is far from a few scripts.
This has been touted, but has there been a non-trivial project that shows this? Something like a media manipulation library where there are lots of places for optimization. It's been stable for a few years now, so I imagine someone's seen performance benefits if it's happened.
One of the big pieces missing here is a picture of what the original design for the Lucas Museum was. Articles elsewhere [1] show just how generic the original plan was. His half-assed mission revival idea snatched defeat from the jaws of victory by being strikingly bland.
Lucas' building was trading a generic store for a generic building that looked more at home housing sleezy mortgage brokers than to be a world-class museum.
Compiler vendors have been resistant towards putting in such features. Bounds checking slows things down, and the performance race is very much a thing in C compiler implementations -- a compiler that can deliver a few percentage points better code can be a big win to teams working on compute heavy problems. C11 has Annex K which has a lot of safety features, like memory safe arrays. Unfortunately, none of the vendors have implemented it even as an option. Which is a shame because it would solve a lot of problems, with requiring minimal rewrites for a lot of code.
In order to support a line running 24/7, you have to build a lot of bits and pieces to include more redundancy. For example, the two miles of Second Avenue Subway has three crossovers, all of which need multiple switches, so that trains can run on either track, allowing maintenance crews to cut power and safely work on the train lines during more quiet hours of the day with minimal disruption. Conversely, BART in San Francisco has very few crossovers. That was cheaper, as signalling and switch infrastructure is expensive, but also makes it much less granular, and as such, harder to do any sort of maintenance.
The big advantage comes from its packaging and everything built into the chip. It comes in a 144 pin lqfp package, which means that routing pins can be done by a couple people with real minimal amounts of training, and it can be laid out onto a two-layer board, which tends to be a lot cheaper than a four layer board which a bga package pretty much requires. It's also got a dac and adc built in which has the circuitry to directly drive headphones, so you don't need amplification circuitry to do that. Similarly, it's got integrated power regulation, so you don't need those chips either. Finally, all the info on it is available in a datasheet you don't need to jump through hoops to read [1]. It's not as fast as a chip, but because of everything it has, it's much more flexible for when you are designing something.
Not really. That little chip is /still/ about the fastest chip you're gonna get for any sort of hardware hacking project for which you want a display, and the ability to prototype using one of the super cheap pcb makers.
This would have been a better project, and had probably gotten a lot more traction, had it provided plugins for the big editor suites -- eclipse, visual studio, etc. As the project stood, it's neat, but at the same time, it's an impedence mismatch. You can't just annotate in your environment of choice, you have to go into a browser window to view the same code you have open in another window and see if there are any annotations. There's a place for something like it, but it needs to be a lot more intimate with how people already work in order for it to get any sort of needed traction.
Yes, because tools hosted elsewhere have the problem your shutdown is exemplifying. A definite expiration date /sucks/. Even if it is a month out, that means having to do a lot of retooling to pull out all the bits and pieces that have been built in that rely on the third party. Were it a hosted solution, a transition plan could be made that isn't a mad rush to make sure all the data that's in those annotations is saved once the lights go out.
Defense could quite practically be a mostly light weight housing that could take a hit or two, and using ducted fans because they're safer and give real good performance. I also imagine that a drone would have a set of cameras for dealing with the hazards of delivery, and would be programmed to avoid people in general, so it would be rare that you could get into a situation where a drone could be stolen.
I've read reports on the incompatibilities, but the odd part is that you can popen which, under FreeBSD at least, is a fairly thin wrapper around vfork() and execve() makes that feel suspect. It may be a bit more work, but commands like this still should be treated as special.
The root cause of this is that PHP's mail function is broken by design. Instead of parameterized values for everything, it passes the entirety of the "additional" options, which includes the from address, as one string for the shell to parse. If the flags were pulled out to individual options to be passed to the command instead, it wouldn't be possible to exploit things in the way it does. So, instead of:
With the result passed to sendmail via the underlying functions, not relying on the shell to separate options for you. Any sort of user-supplied data should be parameterized and treated differently than data you provide. We've mostly learned our lessons from SQL injection, the rest of the stack still has a problem.