binarybanana

The effects of THC aren't an on/off kind of thing. There is a huge range of middle ground between baseline and high in the sky. You wouldn't call someone medicated on Adderall as prescribed by a doctor unfit for driving, either, would you? Yet a person self-medicating the same dosage without prescription is suddenly a danger to others. Which is insane. Same thing goes for THC IMO.

Not to mention that THC's psychoactive effects can be completely blocked by sufficient amounts of CBD and probably other compounds. You can try it yourself. Get CBD drops, ingest 100mg and try getting high. Even the most potent sativa will not work as you might expect.

dcron is very lightweight and has most of those features. Dunno about random delay/timeouts, but worst case those sound like a 10 line shell script away.

https://github.com/dubiousjim/dcron

What makes you think adults don't like flavored liquids?

Seems insane to suggest that adults would prefer the taste of ashtray over apple or orange (I like fruity aromas). I mostly vape without flavoring nowadays because I'm lazy, but I just don't get the mindset. Adults like sugar, sweets, lemonade and all that stuff just as much as children do. Some seem to really like the taste of cigarettes, but I think for the most part people are just more comfortable to say "I like the taste" instead of "I'm addicted to nicotine", because inhaling burnt plant matter along with the diffused active agents and aromatic compounds generally isn't good for taste. Weed also tastes much better vaped.

For anyone who wants to go a similar route I can highly recommend OpenWrt as the OS. Not only does it run on cheap routers, but also on big x86 machines and even in VMs and/or containers. For example, I run OpenWrt on my desktop in a LXC container to manage networking (Wifi, bridging firewall for bridging VMs into the network, general firewall, etc.) through the nice webui. It gets direct to access the WiFi adapter and the host gets access through a bridge connected to the container via a VETH interface.

It comes with nice addon packages for stuff like Wireguard, all kinds of tunnels/VPN, adblockers, runs containers and a ton more. I even run it on a VPS as container with it having exclusive access to the "physical" NIC. The parent OS isn't directly accessible at all. Makes firewalling a breeze. The only open ports are for the Tor relay and Wireguard, through Wich I connect to the webui/ssh and do everything else.

Of course, my router also runs OpenWrt...

If he had Twitter that would be a blast!

Sadly he'd probably get banned like Trump's account.

No fun allowed.

FWIW for portage (Gentoo) there is g-sorcery[0], which can create ebuilds for Emacs (m/elpa) and python packages automatically. Similarly there is also cargo-ebuild[1] which can create ebuilds for rust programs/libraries, including a list of all dependencies with hashes.

I've successfully used cargo-ebuild in the past to create ebuilds automatically, it's a breeze. I'd be surprised if similar tools didn't exist for deb/rpm based distros.

I'm always surprised how many problems people have with python on other distributions. On Gentoo I can install multiple versions at the same time, install libraries for any of those or just a specific python version of my choosing (including pypy), set a default python implementation (pypy) and of course I can pick the version of the libraries I need, too. It's not as flexible as nix, but quite close. Not a python dev though, so YMMV.

[0] https://github.com/jauhien/g-sorcery

[1] https://github.com/cardoe/cargo-ebuild

If you don't need a display manager, you very well might not need elogind,

Yes, that's how I do it. At boot a service auto-logins on all vts and fires up an X server with my WM. Since I already have to enter a password to decrypt the disk this is OK. After half an hour idle/suspend the screen gets locked, so it's not worse than no auto-login.

Sadly, the documentation and wiki has detoriated in quality the last few years. For example I recently tried to look up how to run Xorg without suid, but the wiki had removed the simpler input-group based method in favor of this elogind stuff, which I consider to be worse than useless. Luckily the talk page pointed me in the right direction (history).

Personally, I put -* in make.conf's USE variable and only enable a few things I really want universally like threads, unicode, etc. Then I use flaggie to enable the flags I need when installing stuff. I check with emerge -a to get a list of everything with the possible flags, then enable/disable as necessary. Takes a bit longer the first time, but prevents stuff like this. Sometimes it can break stuff since that's not a supported configuration and might expose undeclared USE flag dependencies, but it's mostly OK.

haven't had cause to use it super regularly

I still sound a bit like an extremely out-of-date teenager.

I don't think it's surprising that the way you speak hasn't changed much when you stopped using the language. Your peers were mostly teens at the time and that's the manner of speech you picked up. Had you stayed in Germany and continued to speak with peers your age it surely would have developed along the way.

Sounds like a lack of exposure to me. With enough experience you should have no trouble to tell if others are speaking in a certain manner that is associated with male, female, child, teen, boss, subordinate, etc. etc. If you can tell you should have no problem talking correctly, or at least the way you want to be perceived by others.

If you can't tell the difference in how others use the language in stereotypical ways, you've basically not yet mastered the language.

I know from learning Japanese a bit myself. People often say using sources like anime and manga will make you sound like an anime character, which I think is ridiculous. Even in anime there are characters that talk quite normally (in fact a lot of them do, depending on what you watch, taking into account their age, gender, who they talk to, occupation and status, etc.) and it's easy enough to tell how actual usage in real life differs in real life by using some other sources, too. But even with only anime and manga as source, just use your brain and don't talk like friggin Naruto and you'd sound pretty normal. Given enough input variety at least.

Same.

I never check the "new" page, but this is the first time I've seen it and I've been reading HN almost daily for over half a decade. 2-3 years before Rust went 1.0 at least.

OpenRC, ironically also reliant on DBUS.

Not at all, although if you have any services that use dbus it might get started by one of them. On my system there isn't even a dbus service file that could be used to start dbus directly through OpenRC. OpenRC works fine without any dbus installed, in fact I'm not even sure if it's even used for any functionality at all. Service control is done through a socket in /var/run/openrc/control (or something), at least on any system configuration I've seen.

That would suck for anything IPv6 (minimum MTU is 1280, as opposed to 576 or something around that).

You can add descriptive error messages when an error happens (like multiple mutable borrows) during macro expansion. Macros are just regular list code, so all runtime features like printing functions are available.

You could even write a FPS using OpenGL where shooting functions, or pieces of suctions removes them from the current compile job (or even deletes them from the source code entirely). In a macro.

Common Lisp does have a "proper strong type system". What it doesn't have OOTB is is static type checking at compile time. Those two are orthogonal issues. Although with CLOS (object system) you get pretty close. Some compilers like sbcl have type inference and you can declare types of variables and function arguments. There are also libraries that take this much further to make it work more like a statically typed language. There are even libraries that add things like dependent types and such crazy things.

Note that static type checking can be difficult to work with when using the prominent interactive programming style since the types aren't always wellhdefined and/or in flux while writing and adding new bits and pieces of code, or redefining types, adding struct/object members at runtime, etc.

But it's possible, yes.

What's the advantage of using the CFS quota mechanism over cgroups cpulimit? I've been using cgroups to successfully make heavy compile jobs unnoticeable by limiting CPU shares to "0" (essentially idle priority) and limiting RAM to 2GB (again, soft limit, uses as much as is available), plus 16GB swap.

It has worked surprisingly well, I can compile Firefox on all cores while playing a game and it's completely imperceptible that anything else is happening, both in terms of performance and interactiveness/latency. No issues with this "burstiness" or stuck/deadlocked processes, either. "Nice" is basically useless in comparison.

I recommend PinePhone.

It used to be part of the kernel back in the day. It was called devfs. It was dropped because a userkspace implementaton is more flexible and easier to extend and tweak. udev also isn't the only choice, mdev also exists and works without running an actual daemon (there is a file in /sys or /proc which specifies a program to run on hardware events, mdev handles the event, then quits).

Of course, nowadays devtmpfs is also a thing, fully kernel space, but not at all configurable. Mostly meant for early user space like initrd and such. But if you don't need anything special it might work for you during regular use, too.

How could a rich existing power exert control over who and how someone uses bitcoin? There is no mechanism by which such control could be exerted.

The worst you can do is monitor traffic and try to correlate wallets and transactions to known identities and products similar to attacks on Tor, then use good old regular meat space violence. Privacy oriented coins like Monitor make this even harder, to literally impossible, too.

I suppose you could start mandating some central registry for wallets or some such and refuse to process any transactions not originating or destined to a registered wallet, but that would require a hard fork and people to willingly go with it.

Technically you don't even need miners, computers, or electricity to exchange cryptocurrency. You can just exchange scraps of paper with a key phrase printed on it that says "wallet contains X btc". The walled could have been emptied before the exchange and that would still require verification by looking at the chain, but otherwise it's perfectly doable, and literal bitcoins do exist.

Sounds familiar?

Windows 10 can run virtually all apps compiled against Windows 2000 just fine, and those apps did not have to bundle their own graphical toolkits.

They do if they're buildtusing Qt, GTK, WxWidgets, etc. Also shipping DirectX and VC++ runtime libraries, .NET runtimes, etc. was and still is (for whatever reason) still common and stuff just doesn't work without it. Plus whatever else the program needs, like a whole python runtime or something.

Is it any wonder that no one can ship and maintain a binary app that targets GTK without bundling it?

Distributions have no problem doing it. If you're shipping something outside the distribution why would you ever expect that shipping only half your program would be feasible? There is no OS where that works.

I do create my own "EFI stub" by embedding the kernel and initrd in a GRUB image as memdisk using grub-mkimage. Then I sign that using my own keys and copy it over to the EFI partition. One cool thing about it is that I can still adjust kernel boot parameters, or load entirely different kernels by mounting the encrypted LVM volume of I really need to. Using the kernel's own stub support this isn't possible, but at the end the grub image still a single self-contained bootable EFI executable file, just like the Linux stub.

I don't share that view. While there are things that I'd really miss in 2000 era Internet today like Wikipedia, GitHub and maybe YouTube, the only thing that really sucked was the IE monopoly (almost like Chrome today) and the Internet connections themselves. Only a few years after that DSL/cable became commonplace and since then the only thing different today is that websites became a lot more bloated and slow.

If you told me in 2000 about the things you listed I'd tell you you're a slowpoke, that's obviously coming and most things were actually already there like SIP, ICQ, IRC, translator software, browsers, etc. existed on the smartphones of the day. What wasn't there was the adoption by the masses, but the tech was there.

IIRC, the other way around. The editor who greenlighted the WIMP paper for print (and only because it was already an established name) regretted this decision once he saw the MACHO paper. Apparently he doesn't like cute names.

IANAP, but they're (among others, like MACHOs, primordial BHs, etc.) potential candidates for dark matter, yes.

The competitors here are nintendo consoles, and the playstation.

Nope, the competition is GPD and other UMPCs. Valve is quite clear about the fact that this is a PC, not a game console. It's a portable gaming PC, but not a console. It's a general purpose computer. I expect a lot of people to install Windows on it, too.

Of course a mathematician improves when gaining nowledge and understanding. The question is how fast that happens and how easily that can be applied in different contexts or how hard it is to even recognize when which fact might be relevant for solving a problem. Knowing something like conformal geometry algebra is useless if possible use cases don't become obvious unless you're just following some form of instructions by someone who does.

I wouldn't say this is a hard rule though as a fresh, unbiased mind can also lead one down an overlooked path with surprising results.

No, that is correct.

There are ways to avoid locks, but the stdlib implemtation doesn't do it. There are probably a bunch of crates that implemented concurrent BTrees, though.

There are ways to make it work. The simplest would be to just not do any splaying most of the time. No splaying means no locking is necessary, just an atomic read to check if anything changed. Apparently it's actually good for performance[1] to splay only occasionally instead of on every access. Another would be to use atomics to do lockless updates. Probably best to only do partial splaying, or only occasionally like above, but it's doable[2].

If the data is actually stored in an array and the tree structure is actually just a map that stores the "nodes" as a tuple (left, element, right) in another array, where left, element and right are indexes into the backing array, then you could just have one such map per thread and only had to use synchronization if anything is added or deleted. Or even have purely thread local addition/deletion if that is sufficient and no locking at all is desirable. A multi-splay tree essentially.

Storing nodes as elements in an array is probably a good idea for performance in general, even in the single threaded case. It means you don't have to allocate each element individually and that things are stored in a contiguous block of memory. The elements are not going to be in the correct order since they fixed in place in the backing array, but they're still going to be much more local than if they're allocated individually. Allocating from an arena/bump allocator would have similar advantages though.

You could also store everything in a single array, replacing the node's element index with the data itself and then use atomics again. This is how I've seen it done in the wild, just without the atomics. Really depends on what you're doing, though. If the individual items are small because they mostly store pointers into some other heap allocated data or just a bunch of numbers, so that the whole map+element structure could fit in the cache, then using multiple maps probably gives better performance.

Can't find any references for this because I just came up with the idea of using multiple maps (not the array storage itself) into a single backing array. Multi-splay trees[3] look close in principle, but they use a reference tree instead of a flat array. It's probably not substantial enough of a difference to really call it a different data structure though.

Edit: Another idea would be a delayed queue splay tree, where some kind of reference to the accessed node gets added to a queue and once the queue reaches a certain size, or some other condition is met, the tree gets locked and all the splaying is done in a single batch. Some operations could even be optimized away if computing that is less costly than doing the operations itself Is. In that case it might actually be useful even in the single threaded case. Somewhere relates to the randomized splaying and probably has been done before though.

[1] http://www14.in.tum.de/personen/albers/papers/ipl02.pdf

[2] https://digitalscholarship.unlv.edu/cgi/viewcontent.cgi?arti...

[3] https://www.cs.cmu.edu/~jonderry/multi-splay.pdf

But what if you had a spinning black hole to play with? Couldn't you strategically place a bunch of satellites in various orbits around it and use the frame dragging effects in either direction to manipulate signals into arriving arrive somewhere else at arbitrary times by sending them around often enough?

I can think of two ways in which one would still be limited though. First is that one is limited to dragging signals only as far back as when the necessary machinery was first put in place. This is analog to the limitation of the wormhole time travel hack where you accelerate one close to c, then slow it back down and put it in place again to increase the distance in time to the other end that was stationary the whole time. But perhaps even worse would be the hard limits on how much this could be used before the whole apparatus itself turns into a black hole by the sheer energy being sent back from the far future. it would be like a time lense effectively. Or less spectacularly, it might just get fried. Or perhaps a failsafe would just dump the signal before things get critical. In any case, there would be a limit to how much or from how far in the future one could use such a thing, but other than that it should work, right?

Ah yes, that would probably explain your experience. OSX might be UNIX certified, but it differs in radical ways from classic UNIX, like file system hierarchy and installed libraries (how many have something like glib installed system wide?).

It's unfortunate (or is it?) but very much not surprising that a proprietary OS would be a second class citizen in an open source ecosystem, especially when dealing with more strongly libre minded free software people like you can expect in larger numbers for enthusiastic hobby projects.

The amount of dirty pages the kernel keeps in RAM is configurable through sysctl. If the buffer is full any further write blocks the process. If you have less free RAM than the allowed dirty page buffer what you said is correct though.

There is a new patch[1] that allows to set a soft and hard minimum of RAM reserved for clean pages. This fixes the problem almost completely even under the heaviest loads.

cgroups like a silbling post mentioned can also help by setting soft limits for heavy background tasks like compile jobs. Setting a soft limit will give them as much RAM as is available, or swap them out completely when things are heavily contented, effectively pausing the processes. It requires some setting up though, so it's not a solution for all cases, but it can make sense even without the thrashing problem.

[1] https://github.com/hakavlad/le9-patch