1,285 karma · joined July 5, 2012
https://web.archive.org/web/20250201145327/https://users.ece...
The person in the forum thread claimed to be repairing CM5s and CM4s. Unusual but it seems like an otherwise hyper reactive response by the RPi Foundation. Something you wouldn’t batt an eye at if it were Apple instead.
ok( conditional, message );
https://testanything.org/Part of the motivation to use processes is because their structure helps to keep the job generic, uni
The last 30 years we’ve seen innovations like dynamic recompilation, fat binaries, JIT VMs, and profile guided optimization. So that has created an expectation of sub-order of magnitude run time performance. It’s a fanciful time we live in.
# Connection successful:
$ timeout 1 bash -c 'cat < /dev/null > /dev/tcp/google.com/80'
$ echo $?
0I believe this is because the commercialization/monetization of Web usage is beneficial to commercial entities. If that isn't possible, then the few who build the Web aren't able to build it in the first place. It's akin OSS and concepts of commercialization in the GPL. You can't create equity if there is no method to transfer value.
HTML not passing the criteria doesn't negate it from being the current leading technology. All it indicates is that there could be a technology that does more (most) of these things better. And, it sets a certain benchmark for the next technology to aspire to.
I think accepting input from anyone is a resiliency feature. Imagine if only Governments drove the Web? Or Multi-national Megacorps? Billionaires? Choice and freedom helps to democratize and enable usage by participants who are diadvantaged.
Content-neutrality is experiential. That is to say, gopher is well known to be more organizationally efficient at transimitting data than http. However, it was primarily aimed at text transmission and was very poor at supporting applications (like banking, commerce sites or email). These were huge boons to the current Web.
Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative) recently published an interesting post on Google+. He’s occasionally contacted by people suggesting a better alternative to HTML but, in all cases, none have come close. Ian states that any technology would need to satisfy at least five objectives to displace existing web technologies:
Be devoid of licensing requirements.
Be vendor-neutral and accept input from everyone.
Be device and media-neutral; it should work on PCs, TVs, mobiles, tablets, screen readers and any future hardware.
Be content-neutral and not restrict itself to types of document or application.
Be radically better than the existing web in every way; faster, more usable, more features, easier to develop, easier to monetize, etc.
HTML can fail objectives two and three. Technologies such as XHTML2 and XForms only satisfied one and three. Java and Flash struggle in all areas — and I’d also add Google’s Dart to that list.
Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?There’s Artifex’s interpreter from muPDF. It’s also the basis of several JS related projects: https://mujs.com/
There’s also a lesser known interpreter: https://github.com/ccxvii/mujs
And IIRC, there was a CommonJS library of the same name.
Still, zclaw is an impressive achievement.
I don't feel like RedHat had to do anything to sell support contracts in this case, because that was already their business. All they had to do was say they'll include container support as part of their contracts.
Correct. Maybe starting with RHEL7, Red Hat took the stance that “containers are Linux”. Supporting Docker in RHEL7 was built-in as soon as we added it to ‘rhel-7-server-extras-rpms’ repo. The containers were supported as “customer workloads” while we docker daemon and cli were supported as part of the OS. What they did do, AIUI based on feedback in the oss docker repos, is those contracts stipulated that you must run RHEL in the container and the host, and use systemd in the container in order to be "in support". So that's kind of a self-feeding thing.
Not quite right. RHEL containers (and now UBI containers) are only supported when they run on RHEL OS hosts or RHEL CoreOS hosts as part of an OpenShift cluster. systemd did not work (well?) in containers for a while and has not been ever a requirement. There’s several reasons for this RHEL containers on RHEL/RHCOS requirement. For one, RHEL/UBI containers inherit their subscription information from their host. This is much like how RHEL VMs can inherit their subscription if you have virtualization host-based subscriptions. If containers weren’t tied to their host, then by convention, each container would need to subscribe to Red Hat on instantiation and would consume a Red Hat subscription instance.https://en.wikipedia.org/wiki/Tiny_Core_Linux#System_require...
https://forum.tinycorelinux.net/index.php/topic,26713.0.html
I recommend asking on that forum. Folks are helpful.