Thinker @ LPThinker @lemmy.world

Person interested in programming, languages, culture, and human flourishing

---

Read more

Posts

4

Comments

58

Joined

2 yr. ago

Since I am not a woman, transgender or otherwise, I won’t comment on the differences or similarities of their experiences. That said, excluding transgender women from a woman-oriented space does not seem helpful or thoughtful to me, just transphobic.

Also, distinguishing between women and females is not something I’m familiar with and don’t feel good about it. It’s certainly self-evident that afab women and transgender women have on average different lives experiences especially during their formative years in which an interest in tech and CS is likely to be either cultivated or discouraged. Nonetheless, given the significant prejudice against transgender people, I imagine few women would begrudge them participation in this community.

The first comment literally wasn't talking about a whole group of people, they were talking about the men in this thread leaving comments that illustrate the exact reason why this space created by and for women and non-binary people should be about and for the benefit of women and non-binary people.

This is such a brain dead take. The conference exists to support a group that has been and is actively discriminated against and harassed in the tech industry. All the men crashing the event care not at all about the conference, its mission, and its participants - they’re just desperate to find a job. And while I absolutely sympathize with people suffering unemployment, it’s really shitty (and sadly so typical and indicative of the problem) to flood a space designed for women and non-binary people, completely disregarding them in the race to get ahead.

Flatpak is definitely the way to go if you’re still getting started in your Linux journey.

The reason that flatpak apps are typically more up to date is because they are most often managed by the actual developer of the app. In contrast, the default apps in the Pop shop (which are deb packages, but that’s not super important) are managed and updated by popos itself (and/or Ubuntu/Debian that popos is built on), which is why they’re often slower to update. The developer has little to no day of when these packages are updated, and usually most packages are frozen between major releases of the distro.

I don't think we should abide hate speech in any format for any reason.

That said, it's concerning that the Australian courts were able to get recompense for Barilaro, yet Barilaro's very real corruption and straight up evil that Friendlyjordies was trying to call attention to has gone completely unaddressed.

I can't claim full understanding, but what I took away from it was that NVIDIA somehow ended up using GPL-licensed code in their proprietary drivers, possibly in a way that could incriminate the Linux kernel if not handled properly. My best guess (as someone with no kernel programming experience) is that NVIDIA sometimes contributes code directly to the Linux kernel that exists solely to support their proprietary drivers (the shims mentioned in the article). Apparently, these shims were exporting GPL-licensed code for use inside the proprietary drivers, which would be a violation of the GPL (unless NVIDIA made the source code for their proprietary drivers freely available in compliance with the GPL).

TLDR: (I think?) NVIDIA essentially infected the linux kernel with license violations to support their proprietary drivers, and the linux kernel devs are working to excise the violations and prevent anything like that going forward.

This is, in part, a correlation. To some extent, compiled Rust is fast because compiling Rust is slow. That is, Rust does a lot of work (static analysis) at compile time so that the runtime binary is as fast as possible.

This is a really neat concept. I love that they're recognizing the tradeoffs of both tiling and floating window managers and imagining a better way.

I think the mosaic idea is interesting and has a lot of potential. I agree with their self-assessment that it's success depends greatly on the simplicity and utility of the window preferred size API, and how willing/able app developers are to adopt it. This is unfortunately yet another place where the fragmentation of the Linux ecosystem shows it downsides.

Nonetheless, I'm really hopeful about this. I would love to see a future where mosaic window management becomes ubiquitous. But really I'd be happy as long as my desktop supports configurable workspaces.

"the only primary difference was that one happens before the aggregation and the other happens after, and all the other implications stem from that fact."

This is correct. The biggest implication of that difference is that, when you filter rows via a HAVING clause, the query will first select all the rows and aggregate them, and only then begin to filter them. That can be a massive performance hit if you thought that the filter would prevent filtered rows from ever being selected. Of course this makes perfect sense, there's no logical way to filter an aggregate without first aggregating, but it's not obvious.

"PRQL's simplification, rather than obscuring, seems like a more clear and reasonable way to express that distinction."

My main point is that PRQL makes no distinction. If you didn't inspect that SQL output and already know about the difference between WHERE and HAVING, you would have no idea, because in PRQL they're both just "filter". Hence, PRQL is not simplifying the complexity (you still need to learn the full SQL syntax and the specifics of how it works), but it does obscure (you have no hints that one of your filter statements will behave completely differently from the other).

As far as removing arbitrary SQL features, I agree that that is it's main advantage. However, I think either the developers or else the users of PRQL will discover that far fewer of SQL's complexities are arbitrary than you might first assume.

Because at the end of the day, SQL it what's being run by the database. For example, in the Showcase on the front page, they have an "Orthogonality" example that demonstrates filtering both before and after an aggregation, which compiles to a WHERE clause and a HAVING clause respectively. WHERE and HAVING have very different impacts on SQL queries, and vastly different performance implications, but the simplification in PRQL obscures that complexity.

At the end of the day, the transpiled langauge will have to either support only a subset of SQL's features, or else be at least as complex as SQL. It cannot support all of SQL's features and yet be less complex, because it is just a wrapper around SQL.

I suppose for the right crowd, possibly people who run queries only once and do not care about performance implications, data integrity, etc., this could be a really useful tool. And in all fairness, they mention exactly that on their homepage:

"PRQL’s focus is analytical queries

PRQL was originally designed to serve the growing need of writing analytical queries, emphasizing data transformations, development speed, and readability. We de-emphasize other SQL features such as inserting data or transactions."

But for developers who need to maintain an application database, I don't foresee this becoming a useful substitute for SQL.

I don't know anything about the newsletter. The core of the article seems to be observing a shift in AI/ML/LLM opportunities. Where before, most people in the field were developing the base models and doing the arduous and highly complex work of training models (what the author calls ML Engineers), now the majority of this field will be people who use those pre-made and pre-trained models, tweaking and applying them for more and more specific and quantifiable uses (what the author calls AI Engineers). He drew a malleable line between the two as whether you're interacting with the model directly or via an API.

This seems nice in theory, but the tradeoffs make me question it's real world viability. It has to be a transpiled language, because SQL is so ubiquitous is may never die. And yet, because it's a transpiler, I'm skeptical that it will actually be easier to write than SQL, because you'll still need to know all the gotchas and eccentricities of SQL.

Maybe for users who already experts in SQL this would be a quaint alternative syntax. However, personally I've already invested so much time developing familiarity with SQL that I see no advantage in moving to a new syntax that would take more time to become deeply familiar with, and that my co-workers won't understand.

This is a fantastic overview of the issue with this proposal, in the broader context of enshittification.

Have been using it since early Alpha days, and I like it a lot but it definitely is still lacking some of the polish of more established tools like Notion.

1. Does it work offline? Yes, it does. Your changes are saved locally and synced at the next opportunity. Obviously this can occasionally cause conflicts but in practice I've never had issues.
2. Does it have databases like Notion? Not exactly. I was never a Notion power user so I can't say how well they compare, but Anytype lets you define your own custom objects with custom relations (sort of like database columns) and link any objects together, as well as creating Sets of objects of the same type and Collections of objects of any kind. So I think in principle it can replicate all the features of Notion databases but in practice you'd want to change how you think about it to fit Anytype's model more easily.
3. Nothing like that yet, although they just open-sourced all their code and the devs are very active on the official forums receiving feature requests.

I think you’re confused on a couple of points.

1. The laptop just released was the 16 INCH framework, not the 16th generation. It is only the second model of Framework laptop, coming after the 13 inch. They have released parts for 3 generations 11-13) of Intel motherboards for the 13 inch laptop.
2. Framework is a fairly new company. They’ve only been around for a handful of years. I believe the very first 13 inch laptops shipped in 2021 (plus or minus a year).

So their track record so far with delivering on their promise of upgrades and repairs is short, but so far it has been stellar.

Yes, that is true. But actually it’s more than that: you don’t need a dev to display static content or a decent commerce page anymore. Square space and it’s competitors give more options at a better value to the layman than devs using PHP or jQuery could hope to these days. We have the simple websites, so frameworks very specifically target productivity and maintainability for complex web apps.

This is not true. The higher complexity of frameworks is unarguable, but it reflects the higher complexity of modern web apps. The reality is that React/Vue/Svelte achieve things that are simply infeasible with e.g. the LAMP stack or jQuery.

I agree with this, Elon is a disingenuous selfish prick, but this source doesn’t provide any indication that Musk admitted anything, it’s just speculation from detractors.

NixOS is a distribution built around the package manger Nix. Nix is not necessarily an iteration of Flatpak ( especially since it’s been around since 2004), but it does accomplish many of the same goals in a more robust way with fewer trade offs.

The main idea of nix is that EVERY dependency of a package is tracked, from the exact glibc version all the way up to e.g. Python packages. I am not a Nix expert, but my surface-level understanding is that this is accomplished by hashing the package and all its dependencies, very aggressively, so that even if a hot fix patch is released that doesn’t change the version number, the new package is still different (as is every package that depends on the new version). That enables Nix to be the best of all worlds as far as sharing system packages like a native dependency while assuring stability and encapsulation like a flatpak. So it ends being as fast and small as the former while being as convenient and cross-distro as the latter. There are other innovations, like declarative dependency management and perfect rollbacks, that make Nix/NixOS stand out, but the above is it's main innovation over Flatpak and older system package managers.

My understanding is that these passkeys can be securely synced - either via your device cloud (e.g. iCloud), or hopefully soon via your password manager. So not that different in terms of UX than current 2FA, but more secure in the backend.