Which packages did you notice that had issues? I'd like to take a look.
6,499 karma · joined November 17, 2015
I was a long time Nova user, so clearly at one point I looked at the F/OSS offerings and didn't love any. But the longer I've used Android, the more I have come to appreciate the way F-Droid calls out anti-features, dependencies on proprietary services, etc. This kind of privacy violating stuff just can't sneak up on you on F-Droid, or get buried in a ton of fine print. (The extreme cases, of course, are patched out altogether lest an app simply be banned from the store entirely.)
In the time since I first gave Nova a shot, the Play Store has become a source of absolute last resort for me, in sourcing apps. I think this time, I'll explore launchers that are exclusively F/OSS, and only via F-Droid, for at least a few months before I even consider recommendations from the Play Store.
The wild thing is that I don't think you need to be either a F/OSS zealot or a miser to get it, at this point. Even if you're fine with proprietary software, even if you don't mind paying for your apps, it's too hard to find apps that are vetted for decent behavior outside of F-Droid. There is no store for "well-behaved, sometimes-proprietary apps".
So that's my recommendation: even if you don't think of yourself as a F/OSS hardliner, consider looking to F-Droid first in seeking your replacement for Nova. There's something relaxing about getting your apps from a supplier that respects you.
Sounds really fun and informative!
> lots of intellectual snobbery about "it feels better"
How does that end up being intellectual (or snobbery, for that matter)? It sounds pretty close to "follow your heart" or "I just enjoy it" to me!
> Although, UNIX was always a confusing term which never really meant all that much to begin with (when talking about commercial OSes/hardware platforms), but that's a whole other conversation...
Seems like a relevant one, for this context ;)
I don't think Apple's choices to deviate from the Unix standard are necessarily for the worst; many are for the better! But their cultural deviation from the norms of the free Unices and Unix-likes is part of what makes computing on macOS feel constraining and frustrating to me. It seems like that sense of disappointment (shared by many others), and defensiveness in response to it, end up driving a lot of discussions around this.
> So, if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin, set the setuid bit on all of these binaries, add /usr/local/bin to your PATH before /usr/bin and /usr/sbin, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers.
https://www.osnews.com/story/141633/apples-macos-unix-certif...
So it seems very fair to say then, that features like SIP and the SSV are genuine turns away from Unix per se, even given the fact of the certification.
Yes.
> Exactly, was it a burglary when your front door is open, lights on, spotlights on your wall safe, with the keys still inserted?
The thing isn't just the discovery of the "open door", though. Thousands of people were extorted in a pretty heinous way. Even if we say breaking in took little sophistication or effort, what was done with the data also matters.
It's also this context that reveals how much simpler strict regular expressions are than general purpose programming languages like Python or JavaScript. That simplicity is also part of what makes regexes so ubiquitous: due to its lower computational complexity, regex parsing is really fast and doesn't take much memory.
When I say regexes are simple, I'm not really talking about compactness. I mean low complexity in a computational sense! As someone who rather likes regex, I think it would be totally fair for a team to rule out all uses of PCRE2 that go beyond the scope of regular languages. Those uses of regex may be compact, but they're no longer simple.
I'm also someone who is sensitive to readability-centered critiques of terse languages. Awk, sed, and even Bash parameter expansion can efficiently do precise transformations, too. But sometimes they should be avoided in favor of solutions that are more verbose, more explicit, and involve less special syntax. (Note also that Bash, awk, and sed are also all much more complex than regex!)
Maybe nothing! I was genuinely asking. I still don't know what Actually Good™ forges are out there these days, generally suitable for corporate use in place of the likes of GitHub or GitLab. Forgejo? Something not based on Git?
That said, what this regex wanted to be was obviously just a list. AWS should offer simpler abstractions (like lists) where they make sense.
- computer science
- computer engineering
- software engineering
- mathematics
- some kind(s) of interdisciplinary programs that interweave computing with fine arts, liberal arts, or business, e.g.,
- digital humanities
- information science
- idk what other disciplines
IIRC, when I was in school, my university only had programs in "computer science", "electrical and computer engineering", "management information systems", "mathematics", and an experimental interdisciplinary thing they called "information science, technology, and the arts". Since then, they've created a "software engineering" major, which I imagine may have alleviated some of the misalignment I saw in my computer science classes.
I loved the great range of theory classes available to me, and they were my favorite electives. If there had been more (e.g., in programming language design, type theory, or functional programming), I definitely would have taken them. But if we'd had a software engineering program, I likely would have tried to minor in that as well!
To me, it's an old-school liberal art (like geometry and arithmetic) that specialists typically pursue as a formal science (that is, a science of logical structure rather than experimentation, like mathematics or Chomskyan grammar). The engineering elements that I see as vital to computer science per se are not really software engineering in the broadest sense, but mostly about fundamentals of computing that are taught in most computer science programs already (compilers, operating systems, binary operations, basic organization of CPUs, mainframes, etc.).
My computer science program technically had only one course on software engineering per se, and I think schools should really offer more than that. In fact, I think that's not enough even within a "computer science" program. But I think the most beneficial way to provide courses of broader interest is with "clear but porous" boundaries between the various members of this cluster of related disciplines, rather than revising core computer science curricula to court students who aren't really interested in computer science per se.
It's not a difficult read, but its authors are leftists and the language may sometimes be difficult for readers with sensitivities related to the goodness of Democrats or Republicans or whatever.
(I think maybe I'll re-read it today as well; it's been a long time.)
Most schools' CS departments have shifted away from letting introductory CS courses perform this function— they go out of their way to court students who are unmotivated or uninterested in computer science fundamentals. Hiring rates for computer science majors are good, so anything to up those enrollment numbers makes the school look better on average.
That's why intro courses (which were often already paced painfully slowly for anyone with talent or interest, even without any prior experience) are being split into more gradual sequences, Python has gradually replaced Scheme virtually everywhere in schools (access to libs subordinating fundamental understanding even in academia), the relaxation of the major's math requirements, etc.
Undergraduate computer science classrooms are increasingly full of mercenaries who not only don't give a shit about computer science, but lack basic curiosity about computation.
The other problem that I tend to hit is a tradeoff between wrongness and slowness. The fastest variants of the SOTA models are so frequently and so severely wrong that I don't find them useful for search. But the bigger, slower ones that spend more time "thinking" take so long to yield their (admittedly better) results that it's often faster for me to just do some web searching myself.
They tend to be more useful the first time I'm approaching a subject, or before I've familiarized myself with the documentation of some API or language or whatever. After I've taken some time to orient myself (even by just following the links they've given me a few times), it becomes faster for me to just search by myself.
I don't think this is really it for many people (maybe any); after all, you can do all of that when writing a text message rather than a piece of code.
But it inches closer to what I think is the "right answer" for this type of software developer. There are aspects of software development that are very much like other forms of writing (e.g., prose or poetry).
Like other writing, writing code can constitute self-expression in an inherently satisfying way, and it can also offer the satisfaction of finding "the perfect phrase". LLMs more or less eliminate both sources of pleasure, either by eliminating the act of writing itself (that is, choosing and refining the words) or through their bland, generic, tasteless style.
There are other ways that LLMs can disconnect the people using them from what is joyful about writing code, not least of all because LLMs can be used in a lot of different ways. (Using them as search tools or otherwise consulting them rather than having them commit code to simply be either accepted/rejected "solves" the specific problems I just mentioned, for instance.)
There is something magical about speaking motion into existence, which is part of what has made programming feel special to me, ever since I was a kid. In a way, prompting an LLM to generate working code preserves that and I can imagine how, for some, it even seems to magnify the magic. But there is also a sense of essential mastery involved in the wonderful way code brings ideas to life. That mastery involves not just "understanding" things in the cursory way involved in visually scanning someone else's code and thinking "looks good to me", but intimately knowing how the words and abstractions and effects all "line up" and relate to each other (and hopefully also with the project's requirements). That feeling of mastery is itself one of the joys of writing code.
Without that mastery, you also lose one of the second-order joys of writing code that many here have already mentioned in these comments: flow. Delegation means fumbling in a way that working in your own context just doesn't. :-\
Anyway, it introduced me to the idea of using computational methods in the humanities, including literature. I found it really interesting at the time!
One of the the terms it introduced me to is "distant reading", whose name mirrors that of a technique you may have studied in your gen eds if you went to university ('close reading"). The idea is that rather than zooming in on some tiny piece of text to examine very subtle or nuanced meanings, you zoom out to hundreds or thousands of texts, using computers to search them for insights that only emerge from large bodies of work as wholes. The book argued that there are likely some questions that it is only feasible to ask this way.
An old friend of mine used techniques like this for dissertation in rhetoric, learning enough Python along the way to write the code needed for the analyses she wanted to do. I thought it was pretty cool!
I imagine LLMs are probably positioned now to push distant reading forward in an number of ways: enabling new techniques, allowing old techniques to be used without writing code, and helping novices get started with writing some code. (A lot of the maintainability issues that come with LLM code generation happily don't apply to research projects like this.)
Anyway, if you're interested in other computational techniques you can use to enrich this kind of reading, you might enjoy looking into "distant reading": https://en.wikipedia.org/wiki/Distant_reading
If someone else would like to make one, though, I'd be happy to read it.