>Vibe coding is more fun than reading documentation. Shit, vibe-coding can be more fun than ordinary coding.
In my experience the big problem is that the documentation is always terrible, you can't ask open-ended questions on stack overflow, the library's reddit (if any) has zero users, and anything asked on their discord is not searchable.
It's incredible that we still don't have a stack overflow that is just a forum.
There are some bad/missing documentations out there, but more often than not, people rush to use the library without first understanding the domain and learning the library's design. Once that's done, the generated api reference and the source code is more than enough to get going.
I guess some people were taught that the Not-Invented-Here Syndrome is a bad thing and needs to be avoided at all costs. And they took it literally.
I had a similar situation at a former job once, where as a subtask of some task we basically needed to implement a "partial deep copy" for a few specific classes (deep-copy some selected properties, shallow-copy the rest), which could either be implemented in ~50 lines of Java code, or by adding an extra library that provided this functionality using a domain-specific language, plus many other things, some of them potential vulnerabilities... and it took a lot of time to convince my team leader that "reinventing the wheel" is the right thing to do in this case.
"Why do you want to program something that already exists? Don't you realize that every line of code you write is a line of code someone else will have to maintain in the future?" Yeah, good points, but it's not like using a library is without costs either: you need to scan for vulnerabilities, increase versions, sometimes the API changes; in long term that is a lot of work to do just to avoid writing 50 lines of code.
> From what I know about C this code probably breaks on platforms that nobody uses.
Your intuition is correct. Even if never dereferenced, casting a compile-time constant other than 0 to a pointer type in that way is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation. [0] If I understand correctly, saving a trap representation to a variable causes undefined behaviour, as doing so presumably constitutes reading the trap value [1] (I had a tough time finding a definitive answer on that point).
I think it would be compliant to use the intptr_t type (assuming it exists on that platform) and give special treatment when it holds -1, i.e. never cast back to the pointer type if it holds -1. (Alternatively, use uintptr_t and give special treatment if it holds UINTPTR_MAX.) This would still rely on the assumption that the special value will never collide with the actual pointer values you need to work with, of course.
In my phone "phone's app" I have the option to message on whatsapp next to each number, but when I click on it, whatsapp doesn't let me just message the number, it asks for permission to view all my contacts.
I feel like we have solved this a billion years ago with the tel: protocol. You don't need full access just to get passed 10 digits by another program?
It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it, or perhaps their developers assume normal people are too stupid to manage fine-grained permissions for all the random apps they put in their PC's?
Maybe the real conspiracy is that the OS developers make the end-user security management terrible to make users afraid of running programs that weren't vetted either by their own proprietary app store where they get paid fees (or in Linux' case, by their distro). Forcing normal users to run a VM to be able to run untrusted apps is prohibitive and restricts the freedom of computer users, in my humble opinion.
As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
WhatsApp can be more specific but chooses not to. They want to access your entire address book and cross-match your number with all of your friends', especially if they're not on WhatsApp yet.
This isn't a technological problem with a technological solution. It's a policy problem on WhatsApp's side.
> As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
Yes, but I wouldn't want my file manager to double prompt me every time I try to delete a file (one from the FM, one from the OS). However, on Android at least, your application can request access to a specific (set of) file(s) or folder(s), so that the damage of a file deletion bug remains very limited. Your app can even request read-only access.
I don't think mobile platform have a good "recycling bin" API, though. There's one for media files, but I don't think that works for general files. Still, the Google Photos/Camera apps seems to use a system prompt to verify deleting files, so I think there's something at least.
And in my experience, users are too stupid to handle fine-grained permissions. Every time I see my parents, I need to go over all of the websites they've somehow managed to permit notifications for (despite my disabling that shit by default), and I'm not the only one. Research shows people will click "allow" without thinking and leave apps running and updating in the background for months before cleaning house. And notifications are only a minor annoyance (at least on Android, other platforms allow them to be pretty annoying), this isn't even about apps trying to track your location by accessing the metadata on your pictures.
For a few decades, we've tried educating people about how to use computers, and wave after wave of viruses proved that most people are incapable of using a computer securely, even with antivirus. In the modern dumbed-down phone landscape, downloading a virus is actually quite hard, and the viruses can do far less damage than what they could in the XP desktop computer era, but that dumbing down comes at a cost. Every unfortunate new sandboxing rule Google imposes on Android (usually) has a very good reason behind it for the vast majority of users, even if it ruins the day or week or month of tens of thousands of power users who rely on the freedom to do what they want with their phones.
> And in my experience, users are too stupid to handle fine-grained permissions. Every time I see my parents, I need to go over all of the websites they've somehow managed to permit notifications for (despite my disabling that shit by default),
so the user is at fault because the browser ignores the user's setting
> and I'm not the only one. Research shows people will click "allow" without thinking
It is because "app developers" insist until the user gives up. Earlier was " ok and " cancel", then " ok and don't ask me again" and now " ok and ask me later".
> and leave apps running and updating in the background for months before cleaning house.
Apps which run by default in the backgroung, with no possibility to stop them. Why does Android does not respect my "force stop" ? Why does it restart the app ?
But yes, blaming the "idiot user" is the way to better UX.
Just jumping in to say that while I absolutely agree that app developers engage in hostile dark patterns, the end-users are nonetheless NOT infinitely blameless. We often forget, those of us here on Hacker News, that we are not the average end-user.
jeroenhd is absolutely correct that people, generally speaking, do not care about fine-grained permissions. We try telling them to use different usernames and passwords, to use pseudonyms, to only give the minimum required access, etc, and yet it just keeps happening. This isn't an access to education issue, it's a stubbornness issue: they don't care to learn it. And in fact, they will look at us weirdly for caring about it so much: I've seen people say that anyone with a protonmail email should get their harddrives checked because only paedos would want that kind of service.
This doesn't AT ALL absolve the app developers for engaging in hostile dark patterns. But I do have to agree that even if the permission system was fixed to be perfect, it wouldn't matter for the vast majority of people because they'll allow everything anyway.
> people, generally speaking, do not care about fine-grained permissions
Even if many people don't care, still it should possible if someone does want fine-grained permissions, to be able to do so (although I think proxy capabilities that I had described elsewhere, would be better than merely "allow" or "disallow", regardless of how fine-grained these "allow" and "disallow" might be).
You are right that it does not absolve app developers.
I think it is a problem with the design of the system (e.g. POSIX), that the permission models do not work very well, so trying to add them to a system that it does not fit, might be the problem. (In some ways, it is possible to do by a VM code, but that has its own issues.)
The other things that you mention might also be significant, although I think the problem I mentioned is also a significant reason why it is difficult to change even if you do want to improve it.
> As a programmer I dread writing any line of code that deletes files
My idea of operating system design does not have any function to delete files. You can erase the contents of a file, and you can remove all references to a file (if you can find them). If you do remove all references to the file, then the file will be deleted. However, any of these things requires a capability which can be used to modify the appropriate files; you do not automatically have the permission to do any of this. (The capability might also be a proxy capability that does copy on write so that the program's view of them can no longer see the contents and references to the file even if they are not actually modified or deleted.)
No, it's not a problem with POSIX, and not even problem with Android (it can pass the number just fine).
It's a design decision of Whatsapp, because they want your full address book so that they can build a social graph and sell you more ads.
You don't need a new OS for that.
(A secondary problem is design of Android system, which allows app to know difference between "permission not granted" vs "permission granted, user has empty address book". But a change like that is fully backward compatible, Google can retrofit this at any moment)
Like you mentioned, it is a design decision of Whatsapp which is a problem, but it is a problem that might be avoided if the system is designed better. Furthermore, some things might be detectable regardless of modifying the system, including timing, and also things which have to do with the instruction set itself. A design which requires the permissions even for timing and all other I/O too (I consider timing to also be I/O), would help, I think.
Using proxy capabilities would allow you to make a "permission granted, user has empty address book" (or some subset of the data, or even made up random data) even if you do not have a empty address book, so that is what I think will be better. (Another way to do it might be to use a separate app for the address book, which does not use the address book in the system. This might work if the app cannot detect the presence of other apps.)
I think adding on to POSIX is not the way to do it though.
My model would be: For a program to access the internet, it must be given a capability (possibly in the initial message, but could also be in a different message), which it can communicate with in order to access the internet. The receiver can't know what capability it is (although it can request a specific capability in the type signature), so it might connect directly or it might use a proxy or simulate slow speeds or error conditions.
A problem is that you describe "access the internet," which is simply too low level for most real applications.
The permission should be "communicate with www.example.com" and if the app needs more than that, you come up with a different permission that is broader.
You want common use cases to have clear permissions so that users can make an informed decision when an app requires much broader access than other apps needed.
> It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it
Not to be a perpetual curmudgeon, but I feel like a portion of the blame for this could the developers XY'ing each other into the broadest use-case possible. Allowing users to select photos to embed into their messages gets "but what are you really trying to do?"-d into just putting access to the filesystem behind a flag.
> In my phone "phone's app" I have the option to message on whatsapp next to each number, but when I click on it, whatsapp doesn't let me just message the number, it asks for permission to view all my contacts.
It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second necessary to get smooth touch scrolling at these screen resolutions.
The demos only show a very limited array of shapes. Precompute the refraction, store the result in a texture, and the gist should be sample(blur(background), sample(refraction, point)). Probably a bit more complicated than this—I’m no magician of the kind that’s needed to devise cheap graphics tricks like this—but the computational effort should be in that ballpark. Compared to on-device language models and such, I wouldn’t be worried.
(Also, do I need to remind you of the absolute disdain directed by 95/98/Me/2000 users at the “toy” default theme of XP? And it was a bit silly, to be honest. It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness.)
> It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness
Great observation! We need some of that sillyness back. Everything is all serious and corporate nowadays, even 'fun' stuff like social media or games. Even movies can't be silly anymore.
Not sure about 'serious and corporate', the big corps like to appear cute, folksy etc. and recently we even saw new Google Material Design advertised as judged more "rebellious" by focus groups. Maybe bland and toothless is just a general direction of contemporary culture and style that they follow.
Myself, I can appreciate corporate stuff presenting corporate. More truthful, feels a little less manipulative.
>It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second
Okay, but what about the battery connected to the GPU? The battery in my iPhone has already degraded below 80% health in the 2.7 years I've had it, so I'd rather not waste its charge on low-contrast glass effects.
> And all of this just to make the whole UI white and generic.
3:30–3:45 in the video is painful. Describing “giving you an entirely new way, to personalise your experience”, while showing… white. White white white. Oh, and light tinted backgrounds to set your white on. I hope the personalisation you wanted was white.
We used to have such customisation, then it kinda went away for a while because it was too hard and limited development, and then dark mode was hailed as a brilliant new invention.
But it is worth remembering that dark mode does actually get you some things; it’s not all bad: the restrictions do have some value.
Full customisation became paradoxically limiting: when you give too much power to the user, the app is essentially operating in a hostile environment. Of course, a lot of it was laziness on app and UI framework developers’ parts, but it really did limit innovation, too.
Dark mode gets you a pair of themes that you can switch between easily, and an expectation that there are only two themes you need to consider, with well-defined characteristics. This is a much more practical target, a vastly easier sell for app and framework developers.
The funny thing with monochrome icons is that in some ways they were actually a better fit for a full-customisation environment, where you had arbitrary background and foreground colours. Once it’s just mundane light and dark themes, you could more safely have full colour in two variants.
Certainly light mode and dark mode does not mean things need to be monochrome.
If browsers got around to actually implementing basic features on browser level like making a frame navigation work instead of coming up with new CSS properties that nobody is going to use we could be all building websites without any javascript.
Now you have to specify whether or not it’s moved during queries (and what if it moves again?) There’s probably a more elegant way I’m not thinking of, but standard created_at and updated_at fields would work: if a given date is <= the move date, it’s the original airport, else the new one. Rinse and repeat if it moves again.
