shatteredgate

>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?

>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.

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.

>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 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

I've read some of their blog series: https://medium.com/raiden-network/raiden-protocol-explained-...

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.

>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.

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.

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.

Sorry, then I must be remembering some other issue. The effort to port docker to BSD seems to have disappeared.

>And yes, having to use root is a major issue. Looks fixable though.

AFAIK it took a long time to get this to work on Linux, there are a lot of security issues that it can cause.

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.

Side note: I suppose you could chroot to /.

>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.

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.

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.

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.

A lot of the various security options in systemd: https://www.freedesktop.org/software/systemd/man/systemd.exe...

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.

Not anymore, unprivileged user namespaces make it so you don't have to do that. That's how podman's "rootless containers" are able to work.

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.

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.

>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.

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.

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

>The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.

I think you're misinterpreting the attitude, or rather that attitude is the same anywhere. GTK and GNOME developers might just be more honest about it, they're fairly limited in what they can do so they can't really fix every single issue on the tracker in a timely manner. That attitude is the same thing with KDE, they have limited time and so can't stabilize things as fast as they'd like. I'd say use Windows or MacOS if you want an OS that is stable and don't want to deal with the limitations of Linux, it's quite far behind on the desktop, and using things like i3wm or swaywm is putting it even further behind because those don't comprise a complete desktop.

>And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.

The problem there is the same, nothing is really native to swaywm or i3wm so you'll probably find that most apps suffer usability issues on them. That's been my experience with third party window managers. If you like KDE apps you probably should use KDE for the most reliable experience.

>I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.

TUIs have a number of other issues so I can't really suggest those either, you're forgoing a lot by making them. There are no perfect options for platform independent GUIs, everything is a trade off. I would personally suggest making web apps or Electron apps before I would suggest TUIs.

And all the other ones: https://man7.org/linux/man-pages/man7/namespaces.7.html

BSD jails are similar but not quite the same thing.

I don't think you can explain that as NIH. From what I have seen, Linux namespaces are a much more powerful primitive than BSD jails.

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.

Yes, you should also remember that when using third-party KDE themes like qt5ct, or hidden KDE settings, or anything else really that wasn't intended by the developer. In my experience with all of those settings, they do work sometimes but with certain apps they can break. That's mostly what unsupported means. I've already said my piece on themes but with keyboard shortcuts, the app can set key bindings that conflict with those and then you'll end up with a broken app again. It's a bad idea to use those settings unless you're willing to revert them at a moment's notice when they break some apps, or unless you're ready to become a developer and fix some of the underlying issues that are causing the breakage.

>despite the apparent impression most people seem to be under when they use GNOME Tweak Tool

I'm not sure what that impression is, GNOME Tweak Tool has always been this way. Other desktops like XFCE can of course expose the setting and make it supported but that's only guaranteed to work with XFCE apps that they've designed to work with that setting.

There are multiple ways to get that though. One of them would be if a lot of hard forks existed, then you'd have a lot of options to choose from. Or those developers can contribute upstream and work on adding tons of options to the upstream project. My point is that there isn't a world where you just get the choice and options out of thin air without programmers, eventually someone has to program the options in somewhere or they just won't exist.

AFAIK there has never been an officially supported way to set those in the GNOME GUI and that's true of everything else in the tweak tool including the themes, that's why they're technically in "use at your own risk because this can break everything and mess up your apps" territory. Those are only implemented as hidden settings that the tweak tool modifies. Not sure about other desktops, XFCE might have a GUI to set them.