Well, this version is going to be in the Ubuntu repos eventually, but might take a while. Ubuntu 26.04 is already in feature-freeze, so it’ll be in 26.10 at the earliest (or 28.04, if you follow the LTS releases).
I guess, it would probably also show up in the “backports” repo before that, if you enable that, but might be easiest to use the Flatpak or AppImage instead…
Obsidian is not open-source…
I just saw this on F-Droid, will need to test it, but sounds like it could be really good: https://f-droid.org/packages/lu.knaff.alain.saf_sftp
I’m hoping, it works like mounting or FUSE on proper Linux, where you can just use normal applications to transparently access network files. Then you’d be able to use any old file manager app to actually work with the files…
You probably just misread, but just to note that SFTP is different from SMB. They’re similar in purpose, but basically competing protocols…
I can understand the sentiment and would 100% agree for programming languages.
But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.
And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
You can just tell them to add the line certificate="/tmp/cert.crt" under [] and they will find a line in their config file which actually reads [] and they can just paste that line as-is.
With nesting, they’d need to add it under here:
network: {
tls: {
certificate: "/tmp/cert.crt"
}
}
Which means:
It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…
VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation. And also shows that they don’t care for using the right tool for the job to begin with.
Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.
We just document that this is how you write the config file:
[network]
bind.host = "127.0.0.1"
bind.port = 1234
# etc.
And that seems straightforward enough. Yeah, technically users can opt to use inline tables or raw strings or whatever, but they don’t have to.
Well, you can still decide how much of the TOML features you actually use in your specific application. For example, I’m currently involved in two projects at $DAYJOB where we read TOML configurations and we don’t make use of the inline tables that OP memes about in either of them.
Ultimately, the big advantage of TOML over INI is that it standardizes all kinds of small INI extensions that folks have come up with over the decades. As such, it has a formal specification and in particular only one specification.
You can assume that you can read the same TOML file from two different programming languages, which you cannot just assume for INI.
Counterpoints:
} or ] can also be a disadvantage of JSON, since you cannot stream it, i.e. start processing the fields/elements before the whole thing has arrived. (You probably still don’t want to use TOML for that, though. JSONL, CSV or such are a better idea.)Well, TOML is essentially just an extension of the INI format (which helped its adoption quite a bit, since you could just fork INI parsers for all kinds of programming languages).
And then, yeah, flattening everything is kind of baked into INI, where it arguably made more sense.
Although, I do also feel like non-techies fare better with flat files, since they don’t have to understand where into the structure they have to insert the value.
They just need find the right “heading” to put the line under, which is something they’re familiar with.
They serve largely different use-cases. JSON is good for serializing data. TOML is good for configuration.
Most developers I’ve looked at would happily just paste the curl|bash thing into the terminal.
I mean, I typically see it used for installing applications, and so long as TLS is used for the download, I’m still not aware of a good reason why you should check the Bash script in particular in that case, since the application itself could just as well be malware.
Of course, it’s better to check the Bash script than to not check it, but at that point we should also advise to download the source code for the application, review it and then compile it yourself.
At some point, you just have to bite the bullet and I have not yet seen a good argument why the Bash script deserves special treatment here…
Having said that, for cases where you’re not installing an application, yeah, reviewing the script allows you to use it, without having to trust the source to the same degree as you do for installing an application.
Firefox Sync is end-to-end-encrypted. Mozilla cannot see your synced data.
Either way, I have no idea how this is supposed to happen without you entering your credentials into Firefox at some point. Even if Mozilla wanted to be sus, they couldn’t just guess which account is yours.
Are you using Firefox Sync with the same e-mail address? I believe, that all gets put into the same account system.
They cause a huge amount of load, deteriorating the service for everyone else. I’m also guessing the time ranges in the graph, where there’s no data, is when OP’s server crashed from the load and had to restart.
That kind of shit can easily trigger alerting and will look like a DDoS attack. I would be pissed, too, if I dropped everything to see why my server is going down and it’s not even proper criminals, but rather just some silicon valley cunts.
My best guess is that they don’t just index things, but rather download straight from the internet when they need fresh training data. They can’t really cache the whole internet after all…
Huh, so if you don’t opt for these more specific number types, then your program will explode sooner or later, depending on the architecture it’s being run on…?
I guess, times were different back when C got created, with register size still much more in flux. But yeah, from today’s perspective, that seems terrifying. 😅
What really frustrates me about that, is that someone put in a lot of effort to be able to write these things out using proper words, but it still isn’t really more readable.
Like, sure, unsigned is very obvious. But short, int, long and long long don’t really tell you anything except “this can fit more or less data”. That same concept can be expressed with a growing number, i.e. i16, i32 and i64.
And when someone actually needs to know how much data fits into each type, well, then the latter approach is just better, because it tells you right on the tin.
Oh man, a zero byte long unsigned integer? Lots of languages represent it as an empty tuple these days (the “unit” type), but from quickly scanning the documentation, it looks like HolyC doesn’t support tuples, so I guess you gotta get creative…
Just to say, though, I feel like 99% of the software we deploy is open-source for that exact reason. Projects generally start out small, where you try to evaluate some concept. You’re not gonna spend months to go through the purchase process of some proprietary tool, if you can help it…