Google diving. I got curious as to what the keyboard controller was, so I looked up motherboard pictures and specs and eventually found that it uses an ENE KB910 for the keyboard controller. Searching there for how things were set up was mostly fruitless, until I stumbled upon a russian forum which had a pinout for the KB910 [1]. A few more stumbles and I found a result that stated that Compal was the OEM for the laptop -- it's not uncommon for laptops to be made by a white box maker. From there, a search for the model number brought up multiple sites with the schematics.
This might be of help to you. The OEM version of this laptop seems to be the Compal LA-2601. Which is a very good thing, because the schematics are readily available [1]. So, getting the keyboard working with a PI3 should be a matter of rigging up a micro with enough pins to drive the matrix controller. Looks like an interesting project though, and I wish you good luck.
It's not. Thunderbolt is a very very closed standard by Intel. With standardized protocols, like regular PCIe, to start building a device, getting started is pretty much a case of ordering a few chips, reading the datasheets, and starting up in a design program. Thunderbolt, on the other hand, in order to even start looking at the datasheets, you have to apply to the developer program, and wait an unknown amount of time for intel to decide if you can even start to develop. Once your device is ready, you have to wait again for intel to approve it, and there is a chance they won't -- the first Thunderbolt GPUs were promised 5+ years ago, but Intel wouldn't approve for them being sold.
This bell seems very well made, designed to last a good long while. Given that a wooden ship tends to have a much shorter lifespan than a ship's bell, it seems possible that Muhayideen Baksh commissioned it with the idea that it would be going on a succession of ships, some of which may not be his, he may have had it cast with such to denote that it was his bell, and not the bell of the ship it happened to be on. So his (ship's bell) instead of (his ship)'s bell.
Things like WPF/XAML can also use an XML-style tree, and the manipulation tools that entails, for UI. However, there are a number of other things they bring to the table that quickly outstrip anything that web-based objects can provide. For example, one can define custom elements, so instead of having a bunch of <Div>s defining things and needing to define things based on ids, you can create a custom tag, like <StatusBar> that gives everything you need plus makes your app layout that much cleaner.
It gets better when you start adding in the things that javascript makes hard, like concurrency and parallelism. For example, with C#, I can do something like
var results = URLs.Select((t) => { Task.Run(SomeLongRunningFunction(t)); } );
to start a series of background tasks handling HTML requests. The equivalent for JavaScript involves the much more restrictive WebWorker API, and requires me to put those small worker functions in their own page/file, or use much uglier data uris which aren't universally supported. HTML/CSS/JS just fall apart once you start getting into more interesting applications.
Recessions on average happen every 8-10 years or so. There was a recession in 91-92, one in 81-82, etc. That part of the business cycle is pretty cyclical.
The kind of border security that Trump is harping on won't stop the heroin epidemic. The cartels have already started shifting to things like drones for pickups and dropoffs [1], or to do more smuggling over the ocean [2]. However, Trump's plan is to slash funding for the Coast Guard, which will just shift the smugglers to using that route more [3]. It may temporarily decrease supply in New Hampshire, but only temporarily, until the supply chains adjust to compensate.
Not to mention never raising the cutoffs. The limit for savings someone on medicaid can have is $2000. That limit was last adjusted in 1989. The limit per month for making money, like getting a side job to try to get back to work, is $20, which has not changed since medicaid was started in 1969. The cost of living amount of $600, which is the amount someone can supposedly live off of, hasn't been changed since 1989 as well. It's hard taking those steps back to independence because like you said, the limits are hard, and also outdated.
Which won't happen until Intel is more willing to loosen their grip on Thunderbolt. With Thunderbolt, in order to even get in the door, you have to file an application to request to get into the development program which they promise to get back to you within three weeks in order to just get the datasheets needed to start designing. Conversely, protocols like PCIe and USB, you can get the chips, the datasheets, and development boards, with no signup process, just waiting a few days for the items to come in the mail. When you treat your customers like that, it's no surprise that the takeup on thunderbolt has been tepid.
It gets more fun when you're dealing with things like memory mapped I/O, where reading from a register is a destructive action, so even a non-overloaded == can cause side effects.
Code like this, there were just as many, if not more, logic errors that wouldn't be caught as there were mechanical problems that would have been caught with a more diligent compiler. There's just not the discipline there for good code, period. Too many corners cut, too much code commented out, etc.
I think with the types of errors you mentioned, that part of it definitely is ecosystem. Look at OpenBSD, for example. They've built things like a safer malloc and fairly extensive patches to gcc that have caught a lot of errors and bugs. I think C/C++ can definitely get safer without changing that much, the ecosystem just needs to get a bit angrier about warnings, etc.
Standardization, and multiple implementations, means you can have multiple sets of compiler eyeballs looking over things. The zcoin bug, for example, emits a warning with the default settings of clang, but doesn't emit a peep with the default settings of gcc. For someone working with a lot of embedded code, it also means that there's a better chance that there's an implementation of the language ready to go when you need to move to a different platform.
Yep. I'd add that if it's a warning you're absolutely certain of, use the warning control pragmas to suppress them, and document why the warning's suppressed. Keep the compiler output clean so you can see where you need to examine.
I'd take that as not even needing to sell what's needed, sell approximately what's needed. Your snake oil just needs to make their cough hurt a bit less, not cure their tuberculosis.
It gets worse for this particular project. They do build with -Wall and -Wextra, but they ignore many warnings that the compiler does emit, and a lot of them are adding/removing a single word. Also, compilers have different default warnings. Gcc doesn't emit a warning on that code, but clang does, for example.
Because pretty much any language that's been touted as a replacement has problems which need solved before they'd really be viable. They're either single vendor with no independent standardization, like Rust or D, or have lower performance like go, or both. Once both problems are fixed, it'll be a lot easier to start looking at alternatives. Until then, there's not a language that settles into a lot of the niches C and C++ operate in.
This case specifically, a lot of the issues that allowed this to happen were logic errors which would have been valid in most languages. A functional language would not have helped very much here.
C and C++ are still used because they work, and have huge ecosystems around them. There's a lot of tooling around them, the compilers build fast, code, and are available for pretty much every planet under the sun. This particular case, it would have helped a lot if the developers looked at the warnings of the questionable code they had made, but they seem to be of the "it compiles, ship it" type that would have let those things fly regardless of the language.
It does. It seems like the devs are of the "it compiles, ship it" sort. Building the source, I'm seeing all kinds of warnings -- the code trying to return consts, warnings about sign differences, etc. Looks like lots of potential places for naughtiness to occur.
This was done in Russia where labor costs are a lot lower. Most construction workers make a fifth of what they make in the states, and I imagine related costs are also lower. So probably a lowball figure, but plausible.
If you're looking to creates something that sounds like it came from the mid-70s, you can either try to fiddle with a bunch of different settings in your DAW of choice to simulate the distortion that a reel to reel provides, or you get a reel to reel from the 70s and not have to worry about if it sounds right for the era/emotions you're trying to catch.
A console like this? It's probably going to end up as the centerpiece of someone's collection, much like Nathan Myhrvold's Difference Engine. It'll be well loved, admired, but rarely if ever actually used. I'd love to be proven wrong though, and have it end up being used as a console for a boutique studio for its unique sound. There's a ton of studio equipment that's kept around "just in case" because sometimes what you're working on calls for something out of the ordinary.
Bottom of the page gives the cost of the foundation -- $277. It also does have an insulated roof, heating, a sink, a bathroom, etc. Electrical, they probably used a wall chaser/cutter to put a groove in to lay the conduit, which was covered when they surfaced the wall. Finish work like that is really similar regardless of the house, and is not really different from what you'd do with a brick surface, etc.
Java promised that, but we got write-once, debug anywhere. Those different features, bugs, permissions, etc, mean you'll still have to test the platforms, build up different UIs for each platform, etc. About all you'd end up gaining is a stylesheet-based rendering engine, but you'd get that with something like XAML as well.
No kidding. HSAs are great if you're healthy. Soon as you have a chronic condition or two where you need to see the doctor on a more than biannual basis, you see where they, and the rest of the insurance system really starts falling apart. A friend I have has several chronic illnesses and is on a pretty typical high deductible health insurance plan you get when you're making $15/hour. Because of this, she can't afford to get treatment for those chronic illnesses due to that several hundred dollar annual deductible just to get into the door. Seeing a doctor would help her greatly, but she's screwed because of the penny wise, pound foolish situation these kinds of plans offer.
In contrast, I'm on disability and on Medicare. Medicare means I pay $6/month for prescriptions which have a "retail" price of $2k, and my copays for regular, non-preventative, doctor visits are $10-$20. Even the doctor fee is because I'm using one not fully within the medicare system. This actually makes it possible to get treatment, even while seeing doctors who specialize in my various medical conditions. Thus I'm getting better, and don't have to balance treatment and finances.
Both. Good support is expensive and rarely a "just". Adding a new supported platform means having to train your support techs in all the quirks that come out in using said platform, and those little things add up in a hurry. On the technical side, each distro has their own similar, but not quite the same, different set of patches against base software and build options which can potentially interact with your software, etc, all of which will need to have regression testing done against before release. Furthermore, software like RHEL itself is supported for a known duration of time, so developers can build their own release and support schedules and not have to worry about getting the rug pulled under them.
Is autocomplete also handled per container? There's an awful lot of privacy sensitive info that can be gleaned from there but it's not listed as being covered.