nrdvana

Actually pub/sub works best when you can commit it in a transaction along with your data changes. When they are separate systems, you get a race condition where you could commit the change but crash before the event gets published.

Because there's an overhead to make a connection, authenticate, set the default parameters on the connection, etc. I've never seen a framework that closed db connections between requests.

Of course, the better design is to write a nonblocking worker that can run async requests on a single connection, and not need a giant pool of blocking workers, but that is a major architecture plan that can't be added late in a project that started as blocking worker pools. MySQL has always fit well with those large blocking worker pools. Postgres less so.

I develop and maintain multiple applications that use a worker pool, and are small enough to run on a single host. We used pg for the user sessions, which get read and written on every single page request. Some of our apps are Internet-facing, and web crawlers can create sessions that get read and written (recording recent pages) as they browse the site. We switched to a redis service on the same host as the app and saw 3 main benefits: faster session loading and saving, less disk activity on the Pg server (so all other queries run faster) and less writes to the Pg WAL, so our backups require drastically less GB per day of retention.

After the significant success of the first conversion, we've been working to convert all the rest of our apps.

And no, host language data structures aren't useful because they aren't in shared memory between all the worker processes, and even if we found a module that implemented them in shared memory, we like to be able to preserve the sessions across a host restart, and then we'd need a process to save the data structures to disk and load them back, and by the time we did that we'd have just reinvented redis.

My understanding is that every electrolytic cap will eventually dry out. The capacitance drifts as this happens, so the quality of the cap and the sensitivity of the circuit to incorrect capacitance will greatly affect how long it takes for the device to fail. The late 90s was also when a large quantity of low-quality electrolytic caps were manufactured.

I've read that electrolytic caps dry out faster if they aren't holding a charge. Temperature is a concern, but I have a surprising number of devices that worked fine before I left them unplugged for a few years and then didn't work when I powered them back up.

The real security flaw is extracting a value from a process's own memory to identify what the process is. If you want a secure way to identify what a process is and where it came from, that needs to be a new feature in the OS.

argv[0] was designed to be part of the arguments to the program, and it succeeds perfectly at that task. The problem is that it has been abused by external tools as a way to identify the program just because there was no other alternative.

It has to be writable because the entire argv string (in program memory) is writable and declared as

  int main(int argc, char **argv)

not

  int main(int argc, const char **argv)

and needs to preserve back-compat. Classic C code might be calling strtok on the arguments, so that block of memory needs to remain writable.

If you know IRC well enough to want to mandate it for your company, you can probably set the server up in an hour or three. You can then install https://thelounge.chat/ and have your employees log into that for browser and mobile apps vs. native IRC clients.

What money would it require? Any leftover PC from the last 15 years can run the server.

I was sort of on the fence for whether to keep using IRC, for years. I used to have Trillian and later Pidgin as a multi-network chat client, and when using one of those, it makes perfect sense to idle in IRC channels. Then the networks got so complex that multi-network clients no longer worked, and now everything sucks and I have to open 3 different browser tabs (Google, Slack, Discord) on my workstation, iPad, laptop, etc to keep up with what's going on with my work clients, and remember not to close them. Even with the mobile apps, messages are often delayed or don't generate proper notifications.

Without a doubt, the modern era is worse than the experience I had in the 2000s. But, it's true that threaded conversations make it easier to collaborate. Email and voice calls used to work fine for that, though.

Meanwhile, I discovered https://thelounge.chat/, and since I have to open too many browser tabs already, what's one more? I'm pretty happy with it. It fills in the missing features of IRC like sending files and images, and being a bouncer.

This looks really cool! though its a bit limited since it is a FUSE module and not a kernel driver, and unlikely to become a kernel module since it is written in C++ with large dependencies :-\

Would it be possible to take the core design changes here and apply them to squashfs, and maybe propose a next major version of the squashfs internal format to make all these things possible?

Well, it depends if your self-rolled version is a complete library, or a quick sidetrack you implemented as a bigger project. If you published it as an installable independent library, and Ruby was using it, I think it's safe to say that you had a complete product. The evil of self-rolled CSV is that people often build on an incomplete understanding of the problem, don't have unit tests, or do something simplistic that necessitates workarounds like this: https://metacpan.org/pod/Data::TableReader::Decoder::IdiotCS...

(case in point, that crazy workaround is only possible because of a large expenditure of effort by the authors of perl's Text::CSV which very few CSV parsers would have implemented)

It's a nice tidy CSV parser, but needs a new title. "world's smallest" is never going to happen in C#, for any measure of "smallest". And aside from that, nobody should be rolling their own CSV parsers if they want to solve real-world problems; use the most capable library your language offers you, which will account for a hundred edge cases yours doesn't.

I just went and read https://bugzilla.redhat.com/show_bug.cgi?id=1381997 and actually seems to me that sshd behavior is wrong, here. I agree with the S6 school of thought, i.e. that PID files are an abomination and that there should always be a chain of supervision. systemd is capable of doing that just fine. The described sshd behavior (re-execing in the existing daemon and then forking) can only work on a dumb init system that doesn't track child processes. PID files are always a race condition and should never be part of any service detection.

That said, there are dozens of ways to fix this and it really seems like RedHat chose the worst one. They could have patched sshd in the other various ways listed in that ticket, or even just patch it to exit on SIGHUP and let systemd re-launch it.

Sadly by 2009 I'd moved on to a new job and didn't have much opportunity to use it. It didn't even have generics when I used it last. Looks like you have to allocate and free them manually though, which is less than I hoped for. I rather like the scripting languages where they are part of the syntax and seamlessly decode from JSON.

Or better, just make an ssh without any dependencies. Statically compile it, and get rid of the libssl and libsystemd and even libpam and libc's nsswitch. (I actually do this for some of my systems)

Well, sshd doesn't depend on liblzma in the first place, but Debian and RedHat thought it would be a good idea to tie it into libsystemd for logging purposes, and patched in support. It's still pretty bad to have systemd compromised, even if ssh weren't, though. Maybe the army of pitchforks should be marching on the systemd camp. It's definitely not OpenBSD's choice of architecture, here.

Delphi kicked ass. Though, looking back, it didn't have hash tables at your fingertips like modern languages. I really can't imagine writing code without hashmaps anymore. Did that ever get added, and in a convenient way that doesn't require declaring a new object each time?

Not using windows much anymore, but great to hear about O&O and ExplorerPatcher. I notice you don't list an ssh client. I still install cygwin for that. Anything new besides putty?

That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override more functions and still succeed.

I'm pretty sure the reason English is hard to dethrone is because Britain ~helped~ forced the various colonies to join world commerce using English, so they started teaching it to entire generations as the national second-language, and then because the USA dominated world commerce after that in a sort of "we'll let you in on the game if you speak our language and use our money" sort of way.

But maybe that's beside the point. If someone wants to "learn French" they can learn by the official rules and communicate with other french-speaking people regardless of how many slang variants exist in France. They can also probably watch French television and understand it.

The point of esperonto was to make it easier to learn. French is regular, but extremely complicated. English is complicated and has a million special cases. Both languages are hard enough to master that society starts to judge a person's intelligence by how well they know the rules and special cases.

Depends on your tools, I suppose. I'd just like to share this:

https://metacpan.org/pod/Data::TableReader::Decoder::IdiotCS...

It would stay regular if there was a strict governing body for it that wasn't a Webster-style "whatever people are speaking is the new definition of correct".

English really is a disaster of a language. There was a(nother) great XKCD about it just a few days ago. https://xkcd.com/2907/

Also not a biologist, but as I understand it: Every living creature synthesizes proteins. Every time you synthesize a protein, there is a tiny tiny chance that it synthesizes "backward". Backward proteins are physically incompatible with "forward" proteins, and also increase the risk that more proteins synthesize backward. It leads to a cascade of errors where lots of proteins synthesize backward and the cells and internal structures can no longer function. It's like you fall apart due to half your Lego bricks being upside-down. And, this is all a statistical probability that could occur in any moment to any living organism.

The evolutionary defenses are to break apart all incoming proteins and reassemble them yourself, and have a cycle of life that starts new organisms from scratch. Large carnivores can't hope to break apart every incoming protein, though. So, basically our lifespans and reproduction method of growing up from a single cell are the evolutionary defenses against the natural phenomenon of prions. But yes, prion disease is probably what forces all higher foodchain animals to avoid cannibalism.

The problem is that you end up with two syscalls for every setting. e.g. chroot to change your own root, then newproc_chroot to change the root of a newly spawned process. Start making a list of all the ways you can change process state and you'll realize there are probably hundreds, here. Now imagine being the kernel author and having to duplicate all that code.

Having used both, I can easily say that CreateProcess is deficient, and fork/exec is kind of genius in how many things it makes possible. Could Windows fix CreateProcess with more API? Sure, but they didn't, probably because nobody wanted to spend the effort duplicating all their kernel code.

Usually to make a program do something the author didn't think of, by passing it a filename to one of its descriptors where the author only gave you a configuration of a path. For example, starting a service under a monitoring system which gives it a pipe to a logger on fd3, then telling it to write a log file of /dev/fd/3

It has real value for as long as there are people who need a currency that isn't controlled by a government. In other words, it's an investment in the working capital of the criminal underworld. (and tinfoil-hatters) The money you put in is probably used to commit crimes of some sort, and the money you take out was probably the result of some crime. But with coins like Bitcoin that have a distributed trust in all miners to maintain the algorithm, I don't think you can say it's a scam.

The ones I think are truly scams are the "stablecoins" and "exchange tokens", which are nothing more than a fiat currency offered by an entity smaller than a government with less accountability than a government, and no way to ensure the value/supply/demand of their coin. So yes, I think FTX was a scam to the extent that they traded FTT while printing or consuming it however they liked.

Yep, but in the end I was able to switch by monitoring the voltage generated by the water on the stainless rods, using a microcontroller. Worked great for a few years until I moved out. Haven't had a sump pump since. (good riddance)

It's important to remember that the pandemic and supply chain mess affected all countries fairly badly, and the US is handling it better than a majority of them. So, even though things are not good, it shows a fair amount of skill in returning the US economy to a healthy place.

The other thing unfair to Biden is that Trump got credit for the unsustainable surge in stock prices after the giant republican tax cut, so it looks bad for everyone's savings as the stock settles back to a normal level.

Rarely does a company make 20M off the work of one engineer. Every 4-5 engineers is another 1M expense, nevermind the other employee salaries. I get kind of annoyed when people look at large aggregate numbers and complain about how different they are from the individual employee pay. Even CEO pay - if they took the entire bonus given to the General Motors CEO and divided it among every employee in the company, it would come out to something smaller than their Christmas bonus. I do think CEOs are generally overpaid and under-liable, but it's not like the CEO salary is directly responsible for workers missing out on the highlife.

And the music industry solution is absolutely horrible. Every single venue that might have someone play copyrighted music is required to pay large annual sums to the RIAA, or get sued. There are armies of RIAA lawyers who go around to basically every business with a lobby and threaten to sue if they don't pay into the pool. There are entire companies who exist just to install licensed players in offices that are known to comply.

Just imagining how awful this would turn out if applied to the world of software makes my skin crawl.