Same. But I guess I’ve just accepted it and moved on. I’m willing to give that up for not having to give up 75% of my wake hours to a purely economic entity.
I think I’m mostly surprised that so many smart/capable/successful people keep grinding long after they need to. And I’m sad that those of us that don’t have a harder time finding eachother because we don’t have a common career to put us in a room together constantly.
Ah well. Wouldn’t trade any of the great adventures I’ve had for a job or a large sum of money. I’m happy with my trade.
Agreed. I don’t use social media of any kind. Not even on the desktop. I always run with Downtime on. All new apps are disallowed from running or notifying unless I whitelist them explicitly.
You really don’t need this “attention porn” in your life. Just turn it all off. Make friends IRL instead. So worth it.
That is all the more reason to make an effort to break the addiction. That is what people do with nicotine.
I do not know of any countries that have banned nicotine. Almost all countries banned sales to kids from a very long time ago, so that was not what changed.
One thing I remember from looking at the industry (I was an investment analyst back then) about 25 years ago, and from my own observations, is that there was a cultural change. Smoking became uncool, a mark of a lack of education. First in the west, and then later globally. Sales of more expensive brands declined, market share moved to cheap brands.
That motivated people to break their addiction and a lot of people gave up as a result. However, everyone with an addiction had to struggle to break it.
Maybe we need more support for people trying to break their social media addiction. Social media addiction anonymous? I guess it still feels like someone trying to give up smoking when everyone did it.
On the other hand, I would encourage you to try. I am very fond of quoting the serenity prayer, and this is something you can control (although its not easy).
You're right about the smoking. Boy did stigma kill that, at least in the US. I still remember bars where you could smoke when I was a kid.
This is an interesting comparison you bring up, because there isn't no stigma around social media, I'd say. It's definitely not well regarded to be on your phone in social settings, at least for my generation. But in private, I know many (incl myself) scroll way more than I'd like. Almost like a smoker sneaking off to get their fix.
A few days ago I came across some idea of having a public readout on a website or something of how much time you spend on your phone, as a way to reproduce this stigma. Unfortunately all the API's to access this data are closed, including iOS. With more access, there could be some really amazing tools to help people use their technology in a way that serves them better, but the people in power would prefer that don't happen...
Compile time. There are preprocessor #if guards all over the code base to provide different implementations for core operations. Many of these are used to provide a thread-safe version (e.g. atomic refcount). Presumably, these should work fine single threaded (assuming correctness). But at the moment they are compile-time, yea.
Am I the only one who thinks this is perfectly fine?
The requirements for derive Clone are clearly defined. As with much in Rust, the type signature drives things, rather than the function body (contrast with C++ generics).
Occasionally, this results in perfectly reasonable code getting rejected. Such is the case with all static languages (by definition).
But in the few cases that happen, the solutions are quite straightforward. So, I don’t feel like it’s justified to add more complication to the language to deal with a few small corner cases.
If you write code manually, you can forget to update it in the future. For instance, a manual implementation of PartialEq might become stale if you add new fields in the future. If you could automatically generate the implementation, and simply guide the macro to use non-default behavior (e.g. skip a field, or use a more complicated trait bound on a generic type) then you can have the advantages of generated code without the disadvantages. Seems worth trying for, IMO.
The real fun thing is when the same application is using “select()” and then somewhere else you open like 5000 files. Then you start getting weird crashes and eventually trace it down to the select bitset having a hardcoded max of 4096 entries and no bounds checking! Fun fun fun.
I made a CTF challenge based on that lovely feature of select() :D You could use the out-of-bounds bitset memory corruption to flip bits in an RSA public key in a way that made it factorable, generate the corresponding private key, and use that to authenticate.
WARNING: select() can monitor only file descriptors numbers that are
less than FD_SETSIZE (1024)—an unreasonably low limit for many modern
applications—and this limitation will not change. All modern applica‐
tions should instead use poll(2) or epoll(7), which do not suffer this
limitation.
You don't have to recompile, just do the following (at least on glibc):
#include <sys/types.h> // pull in initial definition of __FD_SETSIZE
#undef __FD_SETSIZE
#define __FD_SETSIZE 32768 // or whatever
#include <sys/select.h> // won't include the internal <bits/types.h> again
This is a rare case when `-Wsystem-headers` is useful to enable (and these days system headers are usually pretty clean) - it will catch if you accidentally define `__FD_SETSIZE` before the system does.
Note that `select` is still the nicest API in a lot of ways - `poll` wastes space gratuitously, `epoll` requires lots of finicky `modify` syscalls, and `io_uring` is frankly not sane.
That said:
* if you're only dealing with a couple FDs, use `poll`.
* it's not that hard to take a day and think about epoll write buffer management. You need to consider every combination of:
epoll state is/isn't checking writability (you want to only change this lazily)
on the previous/current iteration, was there nothing/something in the write buffer?
prior actual write was would-block/actually-incomplete/spuriously-incomplete/complete
current actual write ends up would-block/actually-incomplete/spuriously-incomplete/complete
There are many "correct" answers, but I suspect the optimal answer for epoll is something like: initially, write optimistically (and do this before the wait). If you fail to write anything at all, enable the kernel flag. For FDs that you've previously enabled the flag for, if you don't have anything to write this time, disable the flag; otherwise, don't actually write until after the wait (it is guaranteed to return immediately if the write would be allowed, after all, but you'll also get other events that happen to be ready). If you trust your event handlers to return quickly, you can defer any indicated writes until the next wait, otherwise do them before handling events.
Checking other libcs (note that "edit the header" is not that difficult to automate):
bionic - must edit the header
dietlibc - must edit the header
glibc - undocumented but reliable, see the dance in the original post
klibc - must edit <linux/posix_types.h> (which, note, sabotages glibc)
MUSL - must edit the header
newlib - documented in header, just `#define FD_SETSIZE` before you `#include <sys/select.h>`
uclibc - as glibc (since it's a distant fork). Note that `poll.c` for old uclinux kernels is implemented in terms of `select` with dynamic `fd_set` sizing logic!
freebsd - properly documented, just `#define FD_SETSIZE` first
netbsd - properly documented, just `#define FD_SETSIZE` first
openbsd - documented just in the header now (formerly in the man page too), just `#define FD_SETSIZE` first
solaris - properly documented, just `#define FD_SETSIZE` first
macos - properly documented, just `#define FD_SETSIZE` first
winsock - properly documented, just `#define FD_SETSIZE` first, but note the API is not actually the same
Oh the real fun thing is when the select() is not even in your code! I remember having to integrate a closed-source third-party library vendored by an Australian fin(tech?) company which used select() internally, into a bigger application which really liked to open a lot of file descriptors. Their devs refused to rewrite it to use something more contemporary (it was 2019 iirc!), so we had to improvise.
In the end we came up with a hack to open 4k file descriptors into /dev/null on start, then open the real files and sockets necessary for our app, then close that /dev/null descriptors and initialize the library.
You’re right. I think it ends up working out to a 4096 page on x86 machines, that’s probably what I remembered.
Yes, _FORTIFY_SOURCE is a fabulous idea. I was just a bit shocked it wasn’t checked without _FORTIFY_SOURCE. If you’re doing FD_SET/FD_CLR, you’re about to make an (expensive) syscall. Why do you care to elide a cheap not-taken branch that’ll save your bacon some day? The overhead is so incredibly negligible.
Anyways, seriously just use poll(). The select() syscall needs to go away for good.
You've had a good chance to really see 4096 descriptions in select() somewhere. The man is misleading because it refers to the stubbornly POSIX compliant glibc wrapper around actual syscall. Any sane modern kernel (Linux; FreeBSD; NT (although select() on NT is a very different beast); well, maybe except macOS, never had a chance to write network code there) supports passing the descriptor sets of arbitrary size to select(). It's mentioned further down in the man, in the BUGS section:
> POSIX allows an implementation to define an upper limit,
advertised via the constant FD_SETSIZE, on the range of file
descriptors that can be specified in a file descriptor set. The
Linux kernel imposes no fixed limit, but the glibc implementation
makes fd_set a fixed-size type, with FD_SETSIZE defined as 1024,
and the FD_*() macros operating according to that limit.
The code I've had a chance to work with (it had its roots in the 90s-00s, therefore the select()) mostly used 2048 and 4096.
> Anyways, seriously just use poll().
Oh please don't. poll() should be in the same grave as select() really. Either use libev/libuv or go down the rabbit hole of what is the bleeding edge IO multiplexer for your platform (kqueue/epoll/IOCP/io_uring...).
Or back in the days of Solaris 9 and under, 32-bit processes could not have stdio handles with file descriptor numbers larger than 255. Super double plus unfun when you got hit by that. Remember that, u/lukeh?
The scrolling effect is very disorienting for me. I want the read the article, but it’s disrupting my focus significantly. Is there a version without all to fancy effects?
I think I did something similar. I decided to severely control my information diet after November and switch to only RSS feeds that I have selected manually and HN. It’s gone better than I expected and I feel very little urge to go back.
At the same time, I’m definitely less informed. Though I’m quite surprised how much still permeates despite me not “going looking”.
Generally, I think it’s more healthy to focus on what you can control and what you have agency over. You can choose what to be outraged over national/global events (and do nothing) or you can instead focus that energy on Doing Something closer to home that’s important to you. Which is the better trade?
I’m somewhat conflicted on being less informed esp with big changes happening. And even more conflicted about what kind of world we’d have if everyone chose this strategy. But, it’s not unprincipled. The principle is Focus on What You Can Control/Do and put all your energy into that.
Well said. Something that occurred to me after writing the parent comment is that this is also an act of protest. Really the only one at my disposal. By depriving these news outlets of my eyeballs I am no longer participating in the incentive structure that created them. Furthermore, our current president is a well-known attention seeker who doesn't care what you think as long as it's about him. The biggest middle finger I can give that asshole is my total lack of interest or attention in anything he's doing.
Yes, but it’s the old skool version of social media and the conversations here are generally higher quality and more genuine. I strongly disagree that it’s “on par with /.,xchan”
HN also doesn’t seem to be as susceptible to rage-baiting / outrage-attention-seeking behavior. Not sure exactly what by this is the case but I’d venture a guess it has a lot to do with (1) “dang”s moderation, and (2) not having a personalized algorithm feed.
I’m increasingly of the view that personalized algorithm feeds generated to select the maximum attention grabbing content for each person is a truly dangerous idea.
Frankly, HN is not that engaging (by modern standards). In fact, probably 60-70% of the articles on the front page are boring to me on any given day. I view this as a feature and not a bug. Why should I expect that everything I look at must be maximally engaging?
There is still a lot of taboo subjects and comments you can make on HN, just look through your comment history on all the things downvoted to hell that you still believe are true. Like a good sheep I now refuse to defend anything that will leave me open to this.
A problem with downvoting on many sites (perhaps HN to some extent) is that people seem to just use it as a generic "I don't like this" button or as part of an upvote/downvote war to make sure that their preferred comment "wins."
I think I’m mostly surprised that so many smart/capable/successful people keep grinding long after they need to. And I’m sad that those of us that don’t have a harder time finding eachother because we don’t have a common career to put us in a room together constantly.
Ah well. Wouldn’t trade any of the great adventures I’ve had for a job or a large sum of money. I’m happy with my trade.
reply