>Should we be telling all the sex workers and adult entertainers that we should be better at "building trust"
Given that the reason there was controversy around OnlyFans was because of scandals about child sex trafficking, I'd say yes. The rest of society should be able to trust that OnlyFans is not providing a platform for trafficking children; crypto payments do nothing to solve that problem, they may even make it worse. They're really good at increasing fees for middlemen though, and it's very frustrating to hear them pitched as a solution to something when the original problem seems to so often get lost in translation.
I'm not going to argue about the specifics of OnlyFans because I'm honestly not aware of the details. In any case, you are missing the point. I could talk about any "legit" adult site and all the extra fees they have to pay because of the risk and credit card fraud associated with the industry, or I could even just use a more "innocent" example such as Gumroad or Steam, who sell only digital content, and would benefit from crypto-payment systems: no chargebacks, no fees for micropayments, no currency conversion fees, etc.
> they're really good at increasing fees for middlemen though.
I can make transfers now of any amount of ETH/DAI for exactly $0.19. [0] This is already competitive with credit card transfers for less than $5. Raiden [1] released today a new version of their client, so you can have decentralized transfers for virtually free (fractions of a cent if the transfer needs to be mediated by other nodes, but basically free otherwise).
I can't see how that is the point, I honestly don't understand what cryptocurrency provides there at all. I've seen nothing about it that suggests it has some kind of novel solution to fraud prevention; no chargebacks just means the customer now has no recourse from a fraudulent vendor, so you've pushed the cost of fraud all onto them. It's also possible to get no fees for micropayments and no currency conversion fees with a more traditional virtual currency, crypto only adds costs on top of that.
>Raiden released today a new version of their client, so you can have decentralized transfers for virtually free
It seems like an interesting way to do peer-to-peer lending, that is not specific to cryptocurrency. I would be interested to see the same algorithm deployed on a credit card network to see if the fees can be reduced even farther.
> no chargebacks just means the customer now has no recourse from a fraudulent vendor.
This is the realm of the social layer, not the technology. You can add an escrow system or even use a reputation-based approach as a way to manage fraud, but the idea is that it is optional. If all you want is to buy some cheap and fast content online, you can't do that with credit card but you can with crypto.
> It's also possible to get no fees for micropayments
Please point me to one micropayment solution that does not involve middlemen and/or extraordinarily high fees (in proportion to the value of the transaction).
> and no currency conversion fees with a more traditional virtual currency, crypto only adds costs on top of that.
Problem statement: you are a software company in the UK and you want to contract a developer based in Argentina. She wants to receive (in Pesos) the equivalent to 500GBP.
Find me some non-crypto alternative where she can get that amount with minimal loss. We can compare notes later if you want, but I can tell you a crypto alternative where the cost is less than 0.3%.
>You can add an escrow system or even use a reputation-based approach as a way to manage fraud, but the idea is that it is optional. If all you want is to buy some cheap and fast content online, you can't do that with credit card but you can with crypto.
I don't understand how this follows at all, the only thing you've added here is that you can't get your money back if the "cheap and fast content" turns out to be a scam. I can't understand why anyone would want this to be optional.
>Please point me to one micropayment solution that does not involve middlemen and/or extraordinarily high fees (in proportion to the value of the transaction).
This would be any virtual currency where you buy it to spend directly with the market operator, the kind you see on prepaid cards in retail stores. That's in the context of a vendor like OnlyFans that runs a marketplace of sorts; if you consider that to be a middleman and you only want some completely peer-to-peer solution then that's a different question with different risks from what we were originally discussing, and most cryptocurrency doesn't fit that definition anyway.
>Find me some non-crypto alternative where she can get that amount with minimal loss. We can compare notes later if you want, but I can tell you a crypto alternative where the cost is less than 0.3%.
I'm not really interested to search around for every exchange I can find and make a comparison, but I would be very skeptical of any crypto-based solution claiming they can lower fees here. The costs of doing bank transfers are the same regardless of whether you use crypto as the medium to move the money. There's probably something else they're doing.
This is getting towards my main problem with these crypto conversations, we're moving away from what the technology actually brings and instead we're getting into only comparing fees without considering any of the other details of what we're actually doing. I find this to be a pointless angle to take; there isn't going to be a period where we use cryptocurrency and we can totally avoid fees, because an explicit goal of every cryptocurrency I've seen is actually to make it so participants can't avoid paying fees. And when you get into smart contracts, every participant can now start acting as a middleman and charging more of their own fees in addition to the transaction and gas costs you pay to the network.
> I can't understand why anyone would want this to be optional.
If someone can make a living by selling e-books/blog posts/Photoshop paint brushes for cents on a dollar to hundreds or thousands of different people - all this person needs is to have people who are willing to take the risk of losing cents of a dollar. When these people pay for the person and actually get what they were expecting, the producer gets the money and the consumers got what they wanted and will then vouch for the producer's honesty.
And if the person is not honest, all it will take is for a few people to lose a small amount of money which is simply not worth fighting for, but it is enough to get those victims to warn others about the scam.
> the kind you see on prepaid cards in retail stores.
This includes middlemen and friction. It's a non-starter as a real alternative to simple payments via crypto.
> I'm not really interested to search around for every exchange I can find and make a comparison.
You really should, because that would be a huge lesson for you and everyone else that criticizes crypto without taking a look at the actual reality of a lot of people.
I specifically used Argentina for a reason: Argentina has strict capital controls and a handful of different exchange rates. If you are an exporter, the central bank converts USD/ARS at one rate. If you are importing, at another. If you are an investment bank at another. "Retail" does not even get to be able to convert money, so they all need to resort to the black market. The difference between the "official" rate and the black market is ~15%. So, someone that wants to receive ARS from someone sending USD (or GBP/EUR...) they will be facing a 15% cut just to be able to cash out.
>And if the person is not honest, all it will take is for a few people to lose a small amount of money which is simply not worth fighting for, but it is enough to get those victims to warn others about the scam.
I am sorry but I don't consider it a positive that someone can clandestinely scam people out of lots of small amounts of money and the only thing an ordinary customer can do is wait until someone else more knowledgeable notices it and then hope they warn everyone and have enough resources to put together a class action suit or just accept that their money is lost because maybe it was too little to care about. At best, this is no better than the current system when using sketchy non-crypto payment systems; at worst, it's asking customers to shelter all of the risk of the product being a scam.
>This includes middlemen and friction.
The point here is that to the market operator, it's actually less middlemen and friction than crypto, they operate the currency directly and so there is no fees for them. It seems like you're shifting from the perspective of the market operator to the customer, but that's not what I was discussing, and it's also not true of most cryptocurrency anyway.
>You really should, because that would be a huge lesson for you and everyone else that criticizes crypto without taking a look at the actual reality of a lot of people.
I don't think it would help because it doesn't explain why the fees would be lower. That's the only question I'm interested in, as far is this hypothetical conversation is concerned. I can pull up a lot of numbers but that's not really giving a full picture. Your description seems to suggest this is illegal in Argentina and you'd be asking your employee to commit a crime, so I suppose that answers my question.
> clandestinely scam people (...) and then hope they warn everyone and have enough resources to put together a class action suit
Do you have any idea of how much money is lost on scams via Western Union? Or how much money companies spend on fraudulent ad views? Insurance fraud?
Before you cry "this is whataboutism", the point I am trying to make is that every security/insurance system is designed around a risk/benefit analysis. There are some situations where the cost of having these systems is simply not worth the value of the transaction, so why should we use it?
Conversely, should we kill every business opportunity just because the cost of avoiding scammers and ill actors is too high? Do you think that Craigslist should be drowned into a see of ineffective regulations because of all the scammers that are there, or should we try to educate people around the potential pitfalls and let it operate in a more organic form?
> The point here is that to the market operator, it's actually less middlemen and friction than crypto
Absolutely not. If I want to sell something online and I accept crypto as payment, I can do it without any middlemen. The only "friction" the user faces is to open the wallet (or scanning a qr code) and pressing "send".
Gift cards force the user to commit to an initial higher amount and to a specific vendor. It's a whole different league.
> I don't think it would help because it doesn't explain why the fees would be lower.
Because you'd be bypassing the central bank, and you would be negotiating with other people who are also trading with the rates from the "blue" dollar (the non-official market). Nothing illegal. Kraken (a crypto exchange) operates on Argentina for years already and any "retail" account can trade there. It's just that the volume there is not big enough yet to make the government greedy about it.
> Do you have any idea of how much money is lost on scams via Western Union?
Which is why we try to move away from that kind of thing, and part of why we're seeing stricter KYC, 2FA requirements and so on. Consumer protection is a hugely valuable part of civilised society, but funding it is a prisoner's dilemma - if you make it optional then people make the individually rational choice to skip it, which is fine until you reach a tipping point where so few people are opting in that the market allows scammers to thrive.
> Do you think that Craigslist should be drowned into a see of ineffective regulations because of all the scammers that are there
Really objective phrasing there lol. No, I think Craigslist and the like should be subject to effective, proportionate regulation (and, sure, in some cases that might mean shutting down a marketplace where there's simply no way to run it and have it not be full of scammers, and I'll defend that as the right decision for the overall public interest), and I believe government for all its faults is better at doing that than blockchain operators.
> I think Craigslist and the like should be subject to effective, proportionate regulation.
In theory, "effective, proportionate regulation" would be great. In practice, we get systems that promote the Surveillance State, regulatory capture and Crony Capitalism, and the implementation of "one-size-fits-all" solutions that eliminate all options to have local autonomous communities.
> Consumer protection is a hugely valuable part of civilised society.
Like I said in the top comment: it's not an either/or proposition. I don't think that blockchain/crypto/decentralized solutions need to replace the existing solutions to be worthwhile. They are worthwhile because they increase our optionality and work as an hedge.
A "civilized society" that requires all people to be subject to the same rules all the time and can not withstand ambiguity and context analysis is a fascist one. The more you see people pushing for this idea that blockchain should be eliminated, the more you will see other people realizing how much it is needed.
The idea that capital should be allowed to act without any oversight or accountability is fundamentally fascist. Wealth distribution follows a power law at the top, so the majority of wealth ends up in the hands of a few or even a single individual - if you say that wealth must be able to be used anonymously and society must not be allowed to stop any mutually beneficial trade between two individuals, then you give those few essentially unlimited power, because there will always be someone desperate enough to do whatever it is they want.
I agree with the need for some flexibility and grey areas. But unrestricted capital is far too dangerous, like private nuclear weapons.
>Do you have any idea of how much money is lost on scams via Western Union? Or how much money companies spend on fraudulent ad views? Insurance fraud?
I'm fully aware, that's why I'm upset that the entire design of crypto seems to be either punting on this problem (to the "social layer" as you said) or is just intentionally making it worse (ransomware). This is not a revolution I can get behind.
>There are some situations where the cost of having these systems is simply not worth the value of the transaction, so why should we use it?
I mean, this doesn't really give any confidence in the value of your transaction if it's so worthless to even matter. Doesn't this just seem a bit fishy to you? After talking to a lot people, I don't think any self-respecting creator online wants to exist in that space for any longer than they have to because it's rife with scams. It's certainly not making me want to drop any money on micropayments any time soon.
>If I want to sell something online and I accept crypto as payment, I can do it without any middlemen.
Well this isn't true, the network itself and the miners (or whatever) is still the middleman. With a currency the vendor operates, there is no middleman at all, you control the whole money supply. Yes the customer still has to pay a form of "exchange rates" when taking cash in and out but that's the same thing as crypto.
>Gift cards force the user to commit to an initial higher amount and to a specific vendor. It's a whole different league.
Again you're changing the discussion to the customer, not the market operator. I don't think this is a reasonable comparison to make because now you're not talking about having a service like Onlyfans any more, you're talking about having entertainers sell directly to customers, which is also a whole different league, probably one that has higher fees because now the creator will likely want to charge more as they now have to offset many other extra costs.
>Because you'd be bypassing the central bank, and you would be negotiating with other people who are also trading with the rates from the "blue" dollar (the non-official market). Nothing illegal. Kraken (a crypto exchange) operates on Argentina for years already and any "retail" account can trade there. It's just that the volume there is not big enough yet to make the government greedy about it.
I still fail to see what the actual practical benefit of crypto here is if the only situations it's really useful is a place where the government has made low cost international bank transfers illegal and you just have to hope they don't come after crypto even though you know they will eventually. It's essentially being propped up by a central financial authority; isn't that the opposite of what crypto is supposed to be?
Read again my very first comment. It does not need to be a "revolution" to be useful. As long as it is can be really useful to some people some of the time, it is already valuable.
> After talking to a lot people, I don't think any self-respecting creator online wants to exist in that space for any longer than they have to because it's rife with scams.
Sorry, that is BS. Plenty of "self-respecting" businesses and people are willing to work just for the expectation of money through advertisements, why wouldn't they work for micropayments?
And again, the idea is to have another option, not to have an all-encompassing solution. It does not have to be a binary choice.
> Again you're changing the discussion to the customer, not the market operator.
Markets do not exist in a vaccum. The whole point of credit cards is that it makes the transaction easier/faster/cheaper for the consumer, so of course you need to look at the solution as a whole.
> the network itself and the miners (or whatever) is still the middleman
No, the network does not charge a proportion of the transaction costs. They provide a service. Do you count your electric company and your ISP as "middlemen" between you and your Amazon purchases?
> I still fail to see what the actual practical benefit of crypto...
>conflates the X protocol and Xlib which nobody was using to write new software even back then.
They are mostly synonymous, there is a large amount of software using Xlib that will likely not ever be rewritten to use XCB. And Xlib is still a better option than XCB if you want to use any client libraries because those all require Xlib.
>He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.
With GTK applications like gedit, it actually is because those are in the category of "won't ever be updated to use XCB". IIRC somebody even tried to port GTK to XCB once and the patches were never merged because it broke everything. XCB is nice for some things but comes with its own set of issues. Please also keep in mind that if you're suggesting the only reasonable solution is to rewrite every client to use a new library, that comes with about the same difficulty as porting to Wayland.
Any mechanism that allows you to listen to hotkeys at will is about as insecure as running a program as root that snoops keys; either way you're vulnerable to keyloggers. The X implementation is quite insecure as well as having a number of other usability issues. I understand your complaints about Wayland but there has just never been any API for this that I've seen on any Linux window system that is actually secure, it just doesn't exist right now. If a secure API is ever implemented, it will probably be made to work with Wayland somehow.
The point is that Wayland architecture is designed to discourage such API, secure or not (I'll also have to check, but AFAIK Wayland went with even less security support in protocol than X11[1] - not XFree/XOrg - so retrofitting is even harder). Same with accessibility et al.
Honestly, Wayland by design feels like MVP that forgot that outside certain limited systems they are missing a lot of "filler" APIs, and somehow assumed it would magically happen by itself. Unfortunately there's no DCOM on Linux in practice, and D-Bus is much more annoying to program against, so the expected "do it in D-Bus" never materialized (and was supposed to cover even things like copy-paste in the original discussions).
[1] X11 servers from vendors other than XFree/XOrg had things like advanced access controls over what applications could do, some integrated with OS-wide Mandatory Access Controls. There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
FWIW I think the goal has been to put security in some other layer that's more appropriate. You can add those type of APIs to Wayland but you'd have to also implement a security mechanism, which is non-trivial. D-Bus can be the most secure option for some things but not here, there might have been a plan to put the clipboard in D-Bus but I believe that got scrapped because it was found to be less secure; Wayland implementations are supposed to validate access to the clipboard based on the most recent input event, to prevent background applications from snooping on the clipboard.
Personally for me I do find D-Bus to be easier to program than Wayland though, the libraries for it are a lot more mature. You might want to try something like pydbus or systemd's sd_bus, or the Rust library zbus. Those are some of the better implementations I've seen.
X11's security mechanisms were never really complete, I don't know of any distribution that actually uses those Mandatory Access Control schemes. Distributions that focus around X security (e.g. Qubes) all seem to use X sandboxing now which should work better than MAC-based security but is quite complicated to set up and still not practical for most other distributions to use. I remember seeing some MAC-based proposals for Wayland but they never caught on because the focus there has also moved to sandboxing.
>There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
AFAIK there is no special part of the protocol for this and this was never really a good solution. It's just done using an ordinary keyboard grab, which are mostly considered an insecure API that does nothing in practice because all the other X security schemes will try to disable or restrict grabs for security reasons.
Ah yes, security through magic fairy. To their credit, at least they went with "you can't break security through nonexistant feature", except a lot of those features tend to be critical for open desktop.
D-Bus is still way more problematic to work with than DCOM. Even on the operation model (something that generic libraries will always have hard time papering over).
As for the X11 extensions - no Linux distro (at least on open market). Because XFree86/X.Org != X11. In fact, XFree86 was essentially lowest common denominator, using with little change a design that wasn't specially good back in 1992. Even if glamor helped some of it, it was more a bandaid than rearchitecting the server (which could have been done without changing protocol).
This comment isn't really correct all, it's not possible to do that with the architecture of X. The best you can get is XSecurity and its related extensions, anything more than that is going to break the protocol. There is quite a good reason that Qubes has not even tried to get X to do this. The main issues are that the protocol is sequential and you can't reorder requests which makes modern polkit-style mechanisms practically infeasible, and also you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib because it is complicated and badly implemented. More about that here: https://news.ycombinator.com/item?id=21267275
BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
> This comment isn't really correct all, it's not possible to do that with the architecture of X.
Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and...
> you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib
...any errors would be the same as if the other clients didn't exist and handled the same way.
Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.
Open source doesn't really work like that, there is no top-down decision maker setting priorities for what should be done in any given distribution. Usually what happens is you wait until it becomes enough of a problem that some distribution fixes it, but this one is low priority given that distributions would probably prefer to focus on native Wayland ports for the software they have control over that is packaged in their distribution. And for the external software they don't have control over, it's much harder to find people to work on those.
^ further, there's the fact that distributions (and the various parts therein) frequently duplicate one another's work in the name of taking different approaches at the same problem, and usually the solutions that become more mainstream are the ones that several of them have collectively settled on.
Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.
Well, looking at the following things sort of gives it away:
- brtfs vs zfs
- cgroups vs jails
- SystemTap vs dtrace
- Systemd vs smf
I get it, many of these were due to licensing issues. So they said[1]. Anyways, there are still some things to implement for linux. pf is my favourite (software) firewall. It would be great to see it ported to Linux.
In my experience, both Linux developers and BSD developers don't seem to care too much about porting things to the other's operating system. If you want to do things the Linux way you can use Linux, and if you want to do things the BSD way you can use BSD. That's seen as easier than trying to glue two incompatible things together.
Won't, not can't. *BSDs shipped GPL components for decades before they decided to go for purity. It's a policy decision, not a incapability or mandate.
I don't see why. BSD and GPL are equally compatible, it doesn't matter which way you go. I can see why they wouldn't want a GPL component to be mandatory but it can be made an optional component for Linux compatibility which seems to be the way BSD would want it anyway.
You can just compare the APIs, namespaces are like the individual components of a jail. You can use them to build something like a jail, or something different that has a different security model. This was discussed a lot in an old HN thread: https://news.ycombinator.com/item?id=13982620
This doesn't really answer the question. Yes, the Linux API seems more flexible, but when you think about it, it really isn't, because all the models that actually make any sense can be implemented using simpler interface, which is what jails provide.
One real difference is that you need to be root to create a jail. It'll get fixed eventually - FreeBSD already has unprivileged chroot, jail isn't that much different.
>Yes, the Linux API seems more flexible, but when you think about it, it really isn't, because all the models that actually make any sense can be implemented using simpler interface, which is what jails provide.
Not really, the example of Docker would probably be the most straightforward there. I don't think it's possible to fully port Docker to jails or at least I've never seen a successful port, some of the network topology features seem to just not be possible or straightforward. But I could be wrong, I have not looked into the technical details of this in years, somebody told me it might have been working a while ago but I never heard anything else about it since.
Needing to be root is a major deficiency though and I can't take jails seriously with that, one of the main focuses on Linux containers in the past several years has been to make unprivileged namespaces a good option.
Docker is practically dead, no wonder if disappeared :-)
Many things are hellishly complicated in Linux, due to politics and technical difficulties. Case in point: when I’ve started to work on NFSv4 ACLs, support in Linux was “worked on”, there was a prototype. It was 12 years ago. In FreeBSD, full supper for NFSv4 ACLs, from file systems to userspace tools, shipped decade ago. In Linux it’s still not there.
Docker wasn't dead 5 or 6 years ago when I heard about this. In my experience some things are easier to implement in Linux and some are easier to implement in BSD. I don't particularly care for BSD's internal politics either, such as the licensing issues mentioned elsewhere here.
It might be because it would require reimplementing all the system-specific Docker parts from scratch. Not sure though.
BSD doesn't really have any licensing issues, thanks to BSD license, but politics is directly related to project size. In FreeBSD it's pretty much unnoticeable, but in Linux it can be a huge deal.
That has not been my experience. The issues are with licenses other than BSD but that's the same in Linux; Linux can also use BSD code, a lot of Linux code is actually dual licensed as BSD already.
It’s not - Linux does have problems with licenses which are incompatible with GPL, such as MPL/CDDL. BSD doesn’t, because you can’t have license incompatibility without throwing GPL in the mix - it’s the only Open Source license that can be incompatible with others.
FreeBSD does avoid pulling restrictively licensed (closed source or GPL) code into the base system itself, but a Docker port would be third party (ports/packages), not the base system.
Not really, with Linux it's the same as it would be in BSD if they wanted to avoid conflicts with GPL. You put that code in an optional module and have the user compile it. I am unsure as to why BSD people seem to think that using BSD means you can avoid problems with the GPL, if you use any GPL code for any reason (and there's a lot of it) then you have to pay attention to these things. If you insist on only running BSD and CDDL code then you can avoid it, but that's going back to putting politics over software again, the kind of thing that you were saying you were trying to avoid.
Also, it’s not politics - it’s mostly just that the old GNU cruft is being replaced, and newer, better solutions prefer more liberal licensing, see GCC vs LLVM.
Well the posix conglomerate had such big problems implementing a ACL (mostly because of blabla)... Then Microsoft did one for NT which was then took over to NFS, later the posix peoples decided on a ACL but no one wanted it anymore. However FreeBSD supports both, but the NFS/Microsoft one is the standard.
Note: Linux also needs root for its namespaces. Or at least CAP_SYS_SYSADMIN, which grants enough that it's pretty much as good as root. See setns(2) and clone(2) for details. This is one of the complaints the plan 9 people have always had with Linux namespaces.
I'm using them for several things but the most straightforward one is probably that namespacing can be gradually added to services, you most likely see benefits from this already if you use systemd. That's one way that namespaces can be used in a different way from the docker model.
What are you adding gradually, specifically? Like, a concrete example that names a namespace you may want to use. I'm trying to figure out what problems a half sandbox solves, and a vague "I just want to enable some capabilities" doesn't help here.
The sandboxing and mount-related ones are implemented with namespaces, and the idea with them is to not make any of them mandatory so they can be slowly added to system services. That way you can get some of the benefits without needing to build a full rootfs/container for the service. I am not sure how any of those would be done with jails because jails require you to create a chroot and network interface, whereas in Linux the mount and network namespaces are just optional namespaces and you can still use the other namespaces without using them.
also, with epairs you can do some really flexible networking stuff on freebsd between jails/jails and the host system and even jails and ipsec tunnels.
And how is it mixing and matching these APIs? Given that there's an OCI-compatible runner for jails (runj, compatible with runc -- which is what docker uses to start containers), it seems to me that Docker isn't in actually using the flexibility afforded by the APIs here, but is just using a relatively fixed set of options.
If I'm wrong: what is it using, and what problems is this flexibility solving?
I haven't tested runj but just from looking at it, it seems it is not fully compatible with everything that runc does because the OCI itself specifies a lot of Linux-specific functionality.
runC is literally the abstraction layer docker wrote internally on top of linux containers! It exists as a separate layer now because they spun it out precisely to freeze the API and enable other efforts like runj.
And runj, IIRC (though I'm not an expert in the space) wasn't a trivial 1:1 thing and required changes to the underlying jails layer to enable it.
There is really no good option for this unfortunately, you will probably run into a lot of issues getting some extensions to work and you still won't be able to use some X11 programs such as those using XCB. Implementing X11 actually needs a large number of extensions to really be functional, probably significantly more than Wayland needs. Not that you should implement Wayland; I don't think this method would even work at all with Wayland. It's probably the right choice though if the goal is to just get a few GTK and Motif programs working and you don't really need them to be fast or use OpenGL or anything. Past that you will probably need to implement a full X or Wayland server that implements protocol-level compatibility.
Not sure who you have been talking to but most Linux developers who I've communicated with have strongly suggested that you do always install updates and don't skip them. It seems it is an equally bad idea to disable automatic updates on Linux as it is on Windows; unfortunately neither of them are formally verified operating systems with any kind of guarantees about correctness and security, so you've just got to keep up with patches.
Linux distros do differentiate between security updates and feature updates. Only the former are recommended to be done automatically.
Microsoft takes the idea of the latter, buries the distinction in the former idea, and shoves "feature" updates down your throat in the name of "security".
> unfortunately neither of them are formally verified operating systems with any kind of guarantees about correctness and security, so you've just got to keep up with patches.
I'm unsure that conclusion follows from those premises, since patches are not formally verified either.
I should have explained it better. Good practice would be to add a regression test when making a bugfix patch, it's not as good as formal verification but it's better than nothing.
I update once a day manually. I build a few packages, but I rely on linux-tkg for the kernel and pull the rest from AUR using git. The Arch Linux package maintainers are very reliable, rolling release is just better when testing is reliable. No big surprises.
I guess, and I would not use it on a production server, but on desktop both Ubuntu and Windows can be unstable as well despite spending months instead of weeks or days testing their updates. Arch keeps it simple, there is not much to test, basically just the core, if the kernel, systemd, X, pipewire and gcc or llvm works I can do my job or take care of the rest. Even if they don't I can take care of it. There is not much to it. One can always revert too, the packages are all git based as well. A working system is always a few commands away.
I used to be a "wait and see" person until I actually took a hard and critical look at a lot of things in the crypto space. It seems evident now that most of it is just poor reinventions of existing financial services, and in some cases (NFTs) just abject scams.
> I used to be a "wait and see" person until I actually took a hard and critical look at a lot of things in the crypto space. It seems evident now that most of it is just poor reinventions of existing financial services, and in some cases (NFTs) just abject scams.
It's pretty obvious that "crypto" (e.g. blockchain stuff) is just clever technology in search of a problem to solve. Its touts keep inventing problems for it, but of out all of them, the only one that's actually stuck is "speculative investment to throw cash at."
I don't think they'll ever succeed, because the problems they identify are already solved by existing technologies and their solutions make worse tradeoffs.
I just expect a bubble burst like the dot com bubble. What stuck was the companies with a real business case, the rest was just mania. And what we learn from that will shape the crypto field going forward.
I agree that SVG/XML is bad for embedded and I think this format is cool but you probably can agree it's unlikely anything will displace SVG unless it matches it in features, one of the benefits which is to manipulate SVGs using the DOM in browsers.
Given that the reason there was controversy around OnlyFans was because of scandals about child sex trafficking, I'd say yes. The rest of society should be able to trust that OnlyFans is not providing a platform for trafficking children; crypto payments do nothing to solve that problem, they may even make it worse. They're really good at increasing fees for middlemen though, and it's very frustrating to hear them pitched as a solution to something when the original problem seems to so often get lost in translation.