binarybanana
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.
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.
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...
Sadly he'd probably get banned like Trump's account.
No fun allowed.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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...
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?
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.
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.