118 karma · joined June 29, 2009
it can show lwn.net
it can show HN
it can show old popular local forum
it can show rss feeds
it automatically blocks (does not work on) all the popular social networks
--
what else is there?
They provide flexibility but at a cost.
I enjoyed Borland Pascal compilation speeds and clean dependencies before switching to Linux. I miss it, together with Delphi.
New Rails with turbo streams is great, but often times it's desirable to do data processing on the client, and then getting back to JS feels like a step down.
- DSL for UI (Forms) - fast native compiler that produced self sufficient binaries - great component library and many open source libraries - Object Pascal was extended to fit perfectly the needs of UI programming
I bought a small usb-to-serial adapter connected to Raspberry Pi Zero W.
Here's a combo with a similar device here:
https://www.aliexpress.com/item/32617788139.html?spm=2114.12...
There are plenty of comparisons available online, but there's a good overview site here: https://aqicn.org/sensor/
Blacklists are needed because OpenGL drivers for specific hardware have bugs and can have missing functionality. Those can affect Wayland too, since the same drivers are used.
Modern Xorg supports direct rendering well, Keith Packard authored a lot of modernized infrastructure such as DRI2/DRI3, and even support for VR (work he's been doing for Valve).
There's also the important VK_display_timing extension implementation he's done with Croateams Alen Ladavac:
https://twvideo01.ubm-us.net/o1/vault/gdc2018/presentations/... on Xorg
Sadly, I don't see much more recent activity from him or Alen about these topics, but it shows that Xorg is still the main platform of inovation for Linux real-time graphics needs.
I've seen just API Gateway costing more than entire infrastructure costs of similarly sized websites.
If you can properly saturate EC2 it will be significantly less expensive than Lambda but with lambda you have to pay API GW and the vendor lock-in price.
I've started flagging these submissions.
My problem with PHP is that most of modern frameworks seem to take a lot from Java, and people have started to use type hinting whenever they can, so the code looks like (uglier) Java, but without advantages of performance (being made worse by having to setup everything on every request) or compile time type safety.
Custom PHP framework we built took into account the way PHP is executed: you are stateless and need to setup everything on every request (runtime is fast to start with FPM and opcode cache). Namespaces based cheap autoloader worked great. No composer. We used singletons for getting the configuration and connections to DBs. There was almost no setup code that needed to be run every time other than loading .ini based configuration and connecting to the DB. Our webapp responded under 20ms (DB and Sphinx included), and I could get it to respond in 1 ms for things where we needed to be quick and didn't have to output HTML with Forms. I was really small and you could read the whole framework code in 1-2 hours. It worked with SQL in a reasonable way. You didn't have to write your SQL for simple CRUD, but for larger things involving joining multiple tables and more complex expressions we wrote native SQL.
I switched jobs, and started with Symfony 3. The thing felt like some Java framework, but poorly documented and harder to use than it should be. It had lots and lots of setup code done before handling every request. There's a whole DI framework with it's own tons of setup code for every component. And you have to do setup even though you don't use the component in that particular request. There's ways of doing lazy setup, but you still waste time to wire that up. Framework overhead can be 30-100ms. Other modern PHP frameworks have similar overhead. I know that there's PHP-PM, to save some of that work that isn't really $_REQUEST specific.
Everybody is using type hints wherever they can, and it feels as verbose as Java, but without compile time type safety, and you can't really put type information everywhere (class members for example). Even though PHP runtime has made great progress (it's probably the fastest interpreted language, and it's great it has reference counted garbage collection), it feels like language is struggling to find it's identity, with it taking a lot from Java and still coping with ugly legacy ($, having to use $this inside a class function, php.ini, features for supporting templating even though it's rarely used as a templating lang in modern frameworks).
Doctrine and it's verbosity feels very ugly to me.
Learning Python and Flask (as an example) was much more enjoyable than switching from a nimble custom PHP framework to Symfony.
I'd argue you can write fast, simple and maintainable PHP, using state PHP runtime has setup for you ($_POST, $_GET, $_SERVER etc), namespaces and a namespace based autoloader, trying to use pure functions when you can (using static classes shouldn't be a sin - just to split your code in sensible parts), and using general good practices for writing readable and maintainable code (avoid long functions, huge classes, too much block nesting, decoupling, naming things in a good way). With some conventions you can write a decent and productive framework quickly, but you could do that with a nicer language too, so what's the point?
Any other suggestions on hackable and cheap H265 capable machines?
Since they have almost 2x of the power budget than the 15W ones, I expect them to be a whole different beasts for loads where you need both GPU and CPU to be active.
Intel is ok too, but their hardware is not really targeted for gamers.
That being said, if you are fine with using proprietary drivers, currently nothing beats nVidia in terms of performance, features and stability of OpenGl drivers.
You would be supporting the ecosystem with any purchase, but if you are politically inclined on free software then the choice is AMD or Intel.
Dota 2 is probably memory bandwidth limited on Intel/Linux/OpenGL and that is likely the case for other games too.
So maybe modifying the OpenGL part of the game engine a bit to take memory bandwidth constraints of Intel GPUs into account would help more.
When I was looking into the issue of Intel GPU peformance on Linux many months ago there were no tools to profile memory bandwidth bottlenecks.
Right now it doesn't perform well at all (using 2x more memory and being significantly slower on Intel GPUs) , and still comes with an annoying sound bug (https://github.com/ValveSoftware/Dota-2/issues/770)
If RAM access is needed ARM machines usually fall behind quickly, since they usually have much lower RAM bandwidth.