I think I much prefer Haskell DSLs over Lisp macros as the basis for APIs in foreign code. That might be due to my relative inexperience with Lisps, but macros just seem to make all the bad aspects of dynamically typed langues much worse. Looking at some piece of code in isolation, not only is it often impossible to tell what is the type/shape of data that are coming in (as is common with dynamic type systems) but with macros added to the mix I also can't tell what the control flow is. So to understand what a single piece of code is doing, I find myself chasing for hints that are scattered throughout the entire codebase.
Contrast this to Haskell's use of DSLs – although they really can be quite dense sometimes, I feel like, when I get stuck, I can always just dig into the documentation on Hackage, and figure out things from the type definitions (even when explanations in docs are lacking). Though it does require being comfortable with the abstractions being used (monads and such). Rust is similar in this manner but to a lesser extent.
But again, maybe the macro critique stems from my inexperience with them.
I use Nix on an ARM single-board computer to host a personal Matrix homeserver (and a bunch of bridges), and I absolutely love it. It's invaluable to have a reproducible specification of the whole system, including custom software to build, in a single place.
That being said, for day to day stuff Arch (and Nix standalone) works well enough for me, to be weary of switching my daily driver PC to Nix, out of the fear of dealing with unforeseen issues and maybe encountering less well maintained packages (there's always something broken on Nix unstable, but maybe it's not an issue for more popular stuff). So I'm sticking to Arch for non-servers for now.
There would definitely be issues with the keyring being outdated which you have to know/search how to work around. And from time to time Arch also requires some manual interventions in the package update process (that are posted on archlinux.org) – you'd have to deal with those all at once if Arch wouldn't have been updated for a very long time. But, other than that, I can't think of other reasons why having a less often used Arch installation would give you trouble.
Then again, I haven't used Arch in such a manner, so you might as well be right.
Doesn't match my experience at all. I love that packages are always up to date. Also, in my experience, having a rolling release cycle leads to significantly fewer issues than having to upgrade everything at once. Using Arch has been a net time saver for me compared to something like Ubuntu where I've wasted a lot of time fighting package upgrade issues and trying to get newer package versions than the distro provides.
Latvian eID also provides cryptographic signing, and it's widely used when communicating with governmental institutions, because it's mandated by law that they must accept such digitally signed documents, and they have the same legal power as regular documents. I believe the situation in Estonia and Lithuania is probably similar. Many businesses also accept them but it's not universal.
Most of the times when I've tried finding stuff in (Firefox) history, I wasn't able to. Unless it's in the last week or so. In my experience, history filtering and search options are too basic to be useful. Once I was even desperate enough to try to load some Firefox sqlite file directly, hoping to query history entries, but that didn't work out.
The only reliable way that I've come across for finding stuff after a long time has passed is saving every sightly interesting webpage to Zotero and using fulltext search afterwards (including webpage body).
I'm curious, do you find the builtin browser history facilities sufficient for your needs, or are you using some third party tool for that?
I wanted to preorder the updated 13 inch model but it turned out that in EU Framework sells their products only in a selected few countries (also they are actively preventing people from using forwarding services so there's no good way to sidestep this). It would be great if they had a distributor somewhere in the EU or something that could resell their products otherwise it might be a very long wait till they're available where I'm at.
I feel like many of the issues people are complaining about here would instantly dissapear if there was regulation preventing content producers and content distributors be the same entity. There's even precedent for a similar thing in USA https://en.m.wikipedia.org/wiki/United_States_v._Paramount_P....
> The extremely short version: The EU is going to task a standardisation body to write a document that tells everyone marketing products and software in the EU how to code securely. This to further the EU Essential Cybersecurity Requirements. For critical software and products, EU notified bodies (which until now have mostly done physical equipment and process certifications) will do audits to determine if code and products adhere to this standard. And if not, there could be huge fines.
Say there is a quantum system – a particle or something – that has an equal probability to collapse in either of two classical states if measured. Say there are two scientists in a laboratory who perform a measurement on that system. If your hypothesis is true, how do they agree on what they perceive when looking at the result of the measurement? Each brain would have to make an arbitrary decision on which of the two equally likely outcomes to perceive.
Do you account for the fact that probability distributions can have multiple peaks with equal probability? If multiple brains were involved, they'd somehow have to coordinate on what they deem the most likely outcome.
I'm curious, shouldn't the "charge only" mode, that's the default, when connecting usb stuff to Android phones, be enough to protect users? Is it really that difficult to implement a "don't read data pins, only charge" mode on a phone and not have vulnerabilities in it?
The "pure utilitarian" viewpoint never made much sense to me because it seems to usually imply accounting for only first order effects, when calculating some costs and gains, and stopping there. I think the secondary effects of not saving people might go far beyond some saved fuel and time in such situations (especially in war, as some have mentioned here).
In other words, optimizing some aspects of a very complex and well functioning system, such as society, locally is likely to mess things up globally.
I think you could create a system that's resilient to such issues even with federation (not saying it's easy, though), and Matrix actually has a solution in the works for this – decentralised user accounts [1].
And all of this makes me wonder – maybe it's better to re-implement something like Mastodon on top of Matrix. If Matrix adopts decentralised user accounts, that would seemingly solve such issues automatically. There was a POC Matrix based Twitter clone demonstrating this, actually [2] (but without the decentralised accounts yet).
I've seen a lot of praise for F# but trying it out left me somewhat disapointed. Overall, it was nice to program in but there was a constant feeling of awkwardness which, it seems, was caused by F#'s ties to the rest of the .NET world. I don't remember the details too well but some of the examples are:
- NULL values still are a problem because they can be introduced any time you interact with the .NET framework. I got hit by this almost right at the beginning when first using the language – i defined some data type with non-optional fields and used it as an argument to an ASP.NET Core controller method only to realize that my non-optional fields don't enforce anything and ASP.NET will happily set them to NULL when data aren't present.
- There are multiple slightly different ways to define data types – classes, records, discriminated unions – and it's not immediately clear what are the consequences of using which. I remember having to switch some of my datatype definitions to classes because otherwise i couldn't make ASP.NET Core automatically deserialize them.
- You still have to learn in detail how all of the C# and .NET concepts map into F# to work with .NET and other libraries, e.g., there is a weird duplication of collection types, sometimes you have to do a weird casting dance with the :> and :?> operators when working with interfaces, dealing with out parameters also took me quite some time to figure out.
- Namespaces, classes and modules also seem to have some confusing redundancy.
I've tried out F# only once for a single project so a lot my complaints are probably due to my inexperience with the language, but all in all it seems that a lot of the suffering is inflicted by the association with .NET and the language could have been a lot nicer if it wasn't tied to it (I'm not dismissing the benefits of it, though).
> Fixing the hardware, which is to say surgically removing the two or three tiny microphones hidden inside, is only the first step of an arduous process, and yet even after days of these DIY security improvements, my smartphone will remain the most dangerous item I possess.
What's the purpose of these microphones? Do they pose more threat than the standard non-hidden microphone?
I don't know enough to think that violation of causality is not possible. It just just seems very unlikely. I can't imagine how the world would look like if it wasn't the case because of the paradoxes it would imply.
You seem to imply that you think differently. Care to elaborate?
Ah, i somehow read the subluminal as superluminal in the abstract and got all excited. But the subluminal restriction makes the paper's findings make more sense.
Contrast this to Haskell's use of DSLs – although they really can be quite dense sometimes, I feel like, when I get stuck, I can always just dig into the documentation on Hackage, and figure out things from the type definitions (even when explanations in docs are lacking). Though it does require being comfortable with the abstractions being used (monads and such). Rust is similar in this manner but to a lesser extent.
But again, maybe the macro critique stems from my inexperience with them.