I'd say put in an ODBC driver. It gets you support for a lot of databases right out the gate, especially if you keep things to a relatively simple subset. That way, someone already running a postgresql or mysql database can plug things in and not need to track another place data is stored.
Those forces are actually pretty well behaved and can be readily measured and accounted for. Also, light sails have a order of magnitude less power, and the Pioneer Anomaly [1] was smaller yet. Space is probably the best place to test something like this.
You really don't want library code providing or dictating malloc behavior, that's how things like OpenSSL and Heartbleed end up happening. It may be slower, but dealing with the politics of a particular malloc can be uglier than just making your code work well enough most of the time.
The patents on the older ARM processors have expired in the past few years, so there are open implementations of the first few generations of architecture. AMBER [1] is one such project.
I grew up as the last oil wells in the South Bay part of LA were being brought down. I've been by the Tehachapi wind farm, the Mojave wind farm, driven past the Solar One/Two demonstration plant [1]. They all have an environmental and observation impact, all the technology does is change where that impact is felt.
Mountaintop removal is still done pretty often because it's the economically cheapest way to do it, damn the economic, social, and environmental consequences of that action.
It's a pretty old chip, and there's a newer generation of Freescale stuff -- the e6500 -- with more cores, smt, pcie 3, etc. Plus, it's kinda expensive compared to other PPC boards. Even the Qoriq reference board is cheaper [1], and reference boards tend to be rather high priced themselves. If you're gonna run Linux, your best bet is elsewhere.
The article got the ethernet situation pretty much completely wrong. The MAC is on the PCH, not on the CPU die. It's not even new, either, dating back to the C200 chipsets of the Sandy Bridge era.
It depends on the type of USB audio device. USB MIDI devices, for example, use bulk transfers because they need reliable communications to handle things like sysex sends. Additionally, Ethernet, through the AVB suite [1] does have time reservation, synchronization, and other things that are very useful in dealing with realtime data.
It may be a pain to only use one connector, but the protocol itself compared to a lot of external busses is a lot nicer. One of the big things ethernet gives is a lot lower latency. The ear is pretty latency-sensitive, with voice latency of 15 milliseconds being a threshold where most people can start noticing. Because of the polling nature of USB, you've got to wait for the bus to ask for data, which means you're going to have at least a couple of milliseconds of latency. Also, because Ethernet is a many-to-many protocol, you can do things like have the synchronization clock on the same connection as data, so you don't need to run a million clock cables along with your data cables.
Not really basic. It's being designed as an urban delivery vehicle, so built for lots of starts and stops, carrying a half a ton of cargo, and be able to maneuver city streets. Those sorts of conditions mean you're going to need a vehicle with a beefy chassis, beefy suspension, engine with a lot of torque and to be comfortable to get in and out of several dozen times a day. Those really aren't all that basic; you're building a freight platform with a wheelbase that's significantly smaller than the traditional freight vehicle. The US postal service is looking at building a similar vehicle to replace their iconic Grumman LLVs, and the entire cost of the program is expected to be into the billions of dollars. You'd be surprised how complicated "basic" can be.
The biggest problem I have with discord is that the client is complete and absolute balls if you want to be in more than one group at once and keep up with notifications and the like. With IRC, my one client shows the activity of all of the networks I'm in, with discord, the only notification I get is that there's "something" going on in another group, without telling the channel, etc. It's much more interrupting and frustrating.
I think that's the biggest flaw with a lot of web-based chats. There's no flexibility in layout. With a chat app like pidgin, I can choose how things are laid out, set up notifications a lot easier, etc. Webapps tend to be a lot more limited in such areas -- not able to choose notification sounds, set various things to notify in different ways, etc.
OP is arguing we should use boats for everything, including sending something across town. Realtime chat works a lot better for certain things, like troubleshooting, where having to wait around for a forum/email response may not be the best way of doing things.
Forums fall apart when you're trying to do things like realtime debugging. With a chat client, I can leave a window open in a corner and keep an eye on it while doing other things. With a forum, that becomes a game of hitting refresh every thirty seconds waiting for new messages.
Slack gets a lot worse once you want to start dealing with two teams using it. With most IRC clients, I can have connections to multiple servers running, and able to see at a glance everywhere that there's activity. With Slack/Discord/etc, that involves a frenzy of clicking as you look through each group of chats individually. I can lay things out how I want, move things around, etc. Slack, fortunately, has bridges built in for IRC and XMPP clients, so I can use my already working clients instead of having to keep another web page open to another javascript-laden nightmare.
It's absolutely possible in such a for the developer to make a fork. People can agree to change licenses, portions can and have been rewritten. Nothing keeps a license in stone.
I'm referring to the GPL's "no other restrictions" clauses that keeps things from interoperating with the Eclipse public license for IBM wanting to maintain choice of venue, the MPL, CDDL, 4-clause BSD, etc. Each of which the FSF says, "well, if they just used our license." The GPL is absolutely a barrier to cooperation.
That same treacherous developer can scoop up talent from a GPLed project too, such as the examples I gave. Sourceforge used to have a GPLed, but was brought closed, and the free version mouldered from disuse. Free software helped expand the reach of proprietary software. The GPL is no guarantee that a free version will always remain the most used branch either.
Going GPL also has drawbacks. Look at how Apache 2 and GPL 2 weren't compatible because of the Apache license's patent clause. That lock-in effect of the GPL means that your software package can't be used by the larger free software community. Which if you're satisfied with it, fine, but some people don't want to encumber their software as such. There's no such thing as a universal benefit.
I'd argue the opposite, that GPL style licenses make it easier to hide things in black boxes these days. LLVM and Clang are under BSD style licenses, and even Sony has said that being an active contributor keeps things moving along [1] even when they don't have to contribute back. Plus, most BSD-style code doesn't require things like copyright assignment, which can be a big brake against people from contributing back.
Additionally, a lot of GPL software, like MySQL and BerkeleyDB, create a more closed community because that company has a lot more ability to create their own black box projects through dual licensing as closed source works. Postgres, in comparison, is BSD licensed, making it much harder for a company like Oracle to buy out pieces of the community and run away with the source and make deals others can't. The GPL has a lot less community power to counter those sorts of situations.
It's more at risk because they have lost sight of what people want. Firefox muddled itself with a halfassed phone project, a programming language, etc, instead of making a good browser, while google poured efforts into making chrome fast and less prone to crashes taking out everything. It's only natural then that they'd lose market share. Free isn't Good Enough, it has to work well too.
The static analysis stuff is something that is in clang's favor. Because of its architecture, static analysis is included, and can be run at compile time through a wrapper called scan-build [1]. So, to get static analysis, most of the time, you just have to run "scan-build make" and it'll do things for you. Clang's clang-tidy tool also handles linting as well, with a misra plugin too [2]. That's the big advantage I see with clang, is that its architecture makes a lot of these things a lot easier to add, which is an area that gcc is just barely starting to address.
The Commodore 64 was also $595 when it was introduced, which, adjusted for inflation, is about $1500. The microbit, on the other hand, is about $20. The microbit also has 256k of flash memory -- in comparison, the 170k 1541 floppy drive cost $400, or $1000 in today's dollars. One also needs to keep in mind that programs can run directly from that flash memory, so that 16k is only really a limitation if you're using python, which won't run on the c64. Furthermore, the microbit has features, like bluetooth and a pair of sensors for movement, that you could only dream of when the c64 was introduced. So yes, the c64 had more volatile ram. The microbit has more of pretty much everything else.
A concurrent GC running on a single processor machine is still going to pause. There are still other ways to get into situations where an attacker can cause the gc to kick in in ways where you can get information -- find a few CPU-heavy functions that nudge the GC to kick in when and where you want it. Harder, but even a background GC can wiggle into the foreground.
For inter-IC interfaces, AMBA [1] and Wishbone [2] are open standards for connecting various sections of a chip --bridge between cpu, i/o bits, etc. External interfaces are also pretty open. A lot of FPGAs have dedicated logic for talking with a PCI bus, I2C bus, etc. Unless you're doing something extremely interesting and specialized, hardware's pretty open as is.
Gull wing doors are about the only thing there that are more complicated than features in other higher end cars. Air suspension's been in luxury cars for several decades, and there are all sorts of complicated locking mechanisms for doors, including pneumatics in various mercedes vehicles. When you start getting into the luxury lines, you start seeing all the added complexity because everyone needs some signature feature to distinguish themselves from just being a nice comfortable ride.