My issue with Ruby (and Rails) has always been the "ball of mud" problem that I feel originates from its extensive use of syntactical sugar and automagic.
> The Nav menu above could be refactored into a Ruby class to allow developers to add items to the menu without needing to understand the underlying HTML.
Either you do SSR and you have to understand HTML or you don't and you can just build a Typescript front-end that calls a ruby server that doesn't generate HTML.
Lets say you do SSR and don't want to understand the HTML, then you can separate the project in two parts and give one part to someone else, but I still don't see how mixing classes and HTML helps.
Functions or templates are enough for SSR, lets be honest this is just about doing OOP everywhere and it creates coupling which IMO is no good.
Took me ages to connect the fact the phone was flipping around at hyper-speed on the webpage because I had the cursor over it whilst scrolling down. Had to move to the right side of the page to then scroll down.
I believe they've somewhat fixed this, it prompts you on first-run whether you want to accept analytics or not. Makes it quite explicit if you want to opt-in or opt-out.
> Homebrew gathers anonymous analytics using InfluxDB. You will be notified the first time you run brew update or install Homebrew. Analytics are not enabled until after this notice is shown, to ensure that you can opt out without ever sending analytics data.
it's ok, sneak literally just comments this on any mention of Homebrew. we've made many changes to analytics but, according to sneak, unless we move to opt-out: we're spyware.
weird how sneak doesn't post this on posts about all of the closed-source companies that use server-side analytics you cannot audit and data you cannot access.
There's no expectation of privacy when you send data to a server. There is when you run local software.
It's unethical for anyone, yourself included, to use an end user's device to spy on them without their consent. Transmitting their activity without explicit opt-in is spying, full stop. It's not spying to monitor your own server when servicing client requests as that is obviously done with the consent of the device's owner (yourself).
I'm not sure why you bring it up; surely you understand the difference between your own computer and someone else's? It feels like you are perhaps approaching it in bad faith.
There is no amount of ad hominem that will make producing and shipping spyware into an ethical choice.
Somehow projects much larger than your own, also run by volunteers, such as Debian, not only survive, but thrive, without spyware of their own, and also with pervasive policies that patch out spyware and phone-home and other such misfeatures in their packages. Nixpkgs manages to continue to grow without spying on their users, too.
If you really thought users would consent, you'd go opt-in. If you maintain the stance that opt-out is acceptable, it is implicit that you believe that not enough users would consent, which means you are intentionally violating their consent given that you know that. Hence, the ethical issue, which handwaving doesn't change.
Debian knows this. It's a shame that Homebrew doesn't. Normally you see for-profit enterprises selling their users out with surveillance; you have no revenue targets to hit so I'm not sure why you persist in this behavior.
> it's ok, sneak literally just comments this on any mention of Homebrew
I wouldn't have to if you would surface for your users when the software you provided them uploads their usage data. Most of your users are unaware of it.
I'll bet you $10k USD cash that if you printed some messages to the console each time you hit the analytics endpoint with a message that "brew analytics off" would disable it, you'd lose a double digit percentage of your inbound data within 100 hours. You won't take this bet and you won't surface the tracking in realtime because you know it's only giving you the data so long as users remain unaware of your unethical behavior.
Also, parhamn explicitly asked for reasons people might switch. This is the primary reason I use Nixpkgs and not homebrew, so it's a direct and accurate answer to their question. You might be surprised but there are lots of people who choose software based on the behavior (and resulting trust level) of the developers.
> There's no expectation of privacy when you send data to a server. There is when you run local software.
To engage on this point: Brew is server software (most installs happen via 'bottles'), no? Presumably most package distros keep track of which packages are installed and how often (e.g. Pip/NPM even publish their data). Even if you install from source github/mirrors/etc they have that data too. I'm sure the same is true in nix too? Curious how you categorized "brew" as not server-y software? And how nix possibly gets around the mirrors/code-distribution services from having access to similar data?
Though my point is mostly moot if you point to a place in the brew source code that is taking more personal information from my computer that a load balancer wouldn't have access to.
> Presumably most package distros keep track of which packages are installed and how often (e.g. Pip/NPM even publish their data).
This isn’t true. Most distributions do not collect this information. There are a few package managers that do as you note, but there are also some that explicitly hide it from package publishers (the Go module proxy cache comes to mind).
Nix and the big linux distros specifically avoid collecting this information. Brew has code to deliver it to additional endpoints without consent.
Extremely well, even supports passing arguments (`--HEAD`) through and integrates with services for casks too, so it can restart things like postgresql when homebrew updates it.
Having nix-darwin uninstall brews not declared in the flake makes me stay honest about keeping my configuration up to date as well, if I've just `brew install x` to try something it'll get removed next time I apply my config. Needs adding to the flake to keep it installed persistently, which in turn means my config tends to be up to date.
> There's a single implementation as far as I know
That's exactly what I mean.
Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.
systemd is is many things, but obvious and accessible is not one of them. It has a lot of power and flexibility, but the trade off is a lot of complexity. Just look at the unit configuration file:
I have no idea from that documentation how I'd run something every hour. I guess I have to create a new unit file, and use the OnCalendar stanza? But what do I set it to? I'm directed to this page:
I started my career as a Unix SA over 25 years ago and have worked with a lot of different Unix-flavored operating systems: SunOS/Solaris, HP/UX, FreeBSD, Linux (Slackware, RedHat, Debian), macOS/OS X, AIX. I'm familiar with all their different variations of init.
All of them are esoteric in one way or another. Some of them have their behavior right out in the open where it's easy to see (inittab and rc scripts). Others hide away massive complexity (launchd and systemd) and require extensive documentation to understand.
I appreciate all the power that systemd provides. It gets a lot of things right. But in terms of complexity, it's almost an operating system unto itself.
I'm not quite sure why you felt pressed to write this long-winded response to something I didn't write. I never said that systemd is easy. I said that if someone is running *BSD, today, in 2024, they'll cope with cron's syntax.
I'll still reply to one part:
> Oh, I see I can use "hourly" but it turns out that's syntactic sugar for:
> *-*-* *:00:00
>Is that really any easier than the cron equivalent?
> 0 * * * *
...Yes? Ask someone who's not familiar either with cron or systemd to guess what each one mean, with the context that it's supposed to be something related to dates and times. If you're vaguely familiar with how dates are usually written down, and that a star is a wildcard, you can immediately guess that the first one means "any year, any month, any day, any hour, at the first minute, first second". The cron one? It's anyone's guess.
Hah, that's fair. I inferred from your comment the corollary that systemd is not arcane, and thought "oh, it's just arcane differently," hence my long-winded reply.
You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo.
Do you take portable to mean a program that can run on every processor arch and OS available?
> Do you take portable to mean a program that can run on every processor arch and OS available?
The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment).
Let's take the context into account:
> hashworks:
While I support systemd timers over cron, AFAIK cron has stuff like @hourly.
> caiusdurling:
Some cron implementations do, it's not portable.
> bheadmaster:
Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly.
However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.
Portable means easy to make it work while changing the underlying system or its implementation details - where the underlying system refers to architecture, OS, API or any other dependencies needed to run the program.
In context of systemd, systemd isn't portable because it highly depends on Linux API and thus cannot be ported on any other UNIX-like (or unlike) OS.
In context of systemd timers, systemd timers aren't portable because there isn't as single alternative implementation that can interpret systemd timer unit files.
I think the MG4 has a brake by wire system, although those are supposed to have a failsafe built in but if it's not electro-hydraulic there might not be a mechanical link between the pedal and the callipers. Handbrake will be electric too, so activation depends on enough of the car brain functioning.
Keyless ignition usually has an override for a running car too, in a ford pushing the button three times within a few seconds turns the combustion engine off. Wonder if that's the same in electric cars, otherwise the only way I can think to kill it is isolate the batteries, same as emergency services would do in an accident.
Another, more detailed account link to elsewhere in the comments pointed out that the police were even on the phone with engineers from the car manufacturer - if there was such a magic sequence apparently it didn't work. Yeah! Software Everywhere!
> Individual devs will still be able to use Sourcegraph for free on public code at sourcegraph.com and within our self-hosted free tier on private code.
> Very few individual devs or companies used the limited variant of code search that was open source. The vast majority (99.9%+) used the enterprise product. Maintaining two variants going forward was a big burden on our engineering team that had very little benefit for users.
A few months back they removed free enterprise license that allowed 10 dev seats, some smaller companies were holding back the updates and looking at the OSS version - I guess, not anymore
First they offered a Free Enterprise tier for 10 seats, they've removed this a few months back, their OSS lacked even some basic things as language support, building it was impossible due to lack of documentation/breakage in the build process for several months and they didn't offer sourcegraph-oss images.
At some point, one individual on Github managed to get it working and his images got 10k+ pulls on DockerHub. That's hardly "nobody". Also, some people removed telemetry from OSS version so Sourcegraph didn't even know that anyone is using it.
Also, they were open-closed-open-closed in the last 5 years.
Their website is a mess, even employees on github are providing contradicting information. Original commit message that relicensed bunch of stuff had errors in it regarding what exactly will be closed source now.
I am using the version you can install via `brew install sourcegraph`, though they seem to have abandoned it to make people install Cody (which requires an account even for local use). I will probably use the Brew version for as long as it works. The major pain point is that it seems to have a timeout for repo discovery at 5s, so you can't just clone all of your GH starred repos and search them this way.
Mastodon is written in Ruby on Rails (: