What I don't understand is with the recent adaptation of GPU-accelerated terminals, why not create something that actually renders Markdown like you'd expect in the browser, but in the terminal? It would have to be significantly faster than the bloat of a typical browser, but just with limited features... like no JS engine.
Those are cool but they are still using just ANSI color codes and what not. I think it is great but not ideal or optimized than if terminals would implement a native markdown or markup renderer.
Wait, how would that even work? Do you want something like SIXL support but for markdown? Encode your markdown doc in an unholy escape sequence and throw it at the terminal?
Signals have some wierd properties; a process-directed signal (i.e. the usual one you’d send with kill) chooses an arbitrary thread and invokes the signal handler. You can get in to some weird situations with signals and threads. If you’re using signals as an ipc mechanism, a useful tip is to just block the signal and register a signalfd on poll/epoll to regain control flow control.
The classic solution would be to fork a special signal catching thread and play with the signal masks to ensure the signal goes there. This is what glib does if I recall correctly.
... Which of course seems very silly today. Signalfd is a much nicer API to use for new programs!
I had this issue in a case I think is interesting; a customer had a database with incremental IDs of a certain product they sold. On a web platform, the product owner in turn could log in and view a list of their products and their status. The id of the product was part of the URL; /product/851. Of course, the product owners could not get any information on IDs they didn’t own, but the numbers gave away info on how many devices existed before them. And they wanted to hide that information.
Of course, there are many ways to solve that situation, but UUIDs is one.
Just pick a random number at the beginning, and start incrementing IDs from there. Like personal checks starting at 1000 so they're always(ish) 4 digit. Of course, maybe pick another starting number that's less obvious.
Poettering makes some really valid points in this post; you shouldnt be using select. And the resource limits are weird. But I just want to consider that open fds are a resource hog, and you should also strive to close fds sooner rather than later. Most applications will stay well below 1024 fds, and if they consume more then that - it’s probably a bug.
Servers, sure; each connection can easily consume 2-3 fds, that’s 300-500 simultaneous connections - that’s nothing.
Systemd and other service supervisors, sure, with pidfds, timerfds, sockets, proc file sockets and whatever else.
But for your average image editing softwares, email clients, CLIs, etc; id think it’s probably better to keep the limit? That way you are saving yourself from badly written software draining too much resources.
I'm not sure I buy the idea that "efficient and easy tooling around a technology makes the technology". We all went through the same Dreamweaver pains.
How come the minuscule userbase of native frameworks have better tooling than the numero uno popular web? It may mean that there is a technical reason in the background.
They solve a simpler and more constrained problem which makes it easier to make tools. Something like Windows Forms are basically WYSIWYG - you drop some controls on a canvas and now you have a GUI. But the GUI will not gracefully adapt to different screen dimension from large monitors to mobile.
It's younger than the web but much older than the current bunch of frontend technologies. JavaFx is from 2008 [1]
Anyway, that's not very important.
What web apps never had is a visual app builder as popular as the first Visual Basic for Windows 3. We had some tools like that (example Jwt [2]) but none of them got a critical mass of users. Maybe it's difficult to match Visual Basic's success because Microsoft controlled the tool, the operating system and the language. If this is the case the only current candidate is Google, because of Chrome. They are investing on Flutter and Dart now but making them prosper on the web looks like a uphill battle. Much easier on Android.
The reason why TimescaleDB is so fast relies really a simple concept; keep indexes small enough to keep in memory. If you have a small enough index, you only need to do 2 reads from disk; one for the index to locate the data, and then one for the actual data.
Fetching data becomes much, much slower once your index is too large to fit in main memory. TimescaleDB segments the indexes into chunks (the “hypertables”) and makes sure these chunks are all “small enough”.
This alleviated further by having the data sequential by time; inserting new data does not need to alter older index chunks, which is what makes inserts fast.
I can imagine that if that’s not the case and your inserts are altering “older” chunks so data needs to move between lots of chunks could make the database prohibitively slow.
This is really cool.