Is this right? These tools don't show ignored files because they aren't part of the repository. If a now-ignored file has made it into the repository, surely you want to see it?
Is this right? These tools don't show ignored files because they aren't part of the repository. If a now-ignored file has made it into the repository, surely you want to see it?
There are 7 or 8 repositories now in this org. Feel free to take, use, or help imrove the code. MIT Open Source.
Would it be possible, that the storage of pypi/whatever is some s3 bucket, where you have it encrypted (with authentication), and when you deliver it to a client, you get it, decrypt it, test for authentication and deliver it to the client? the encryption is something that artipie is lacking sadly.
will your stuff be really opensource?
Nothing against systemd, but hardwaring is not a good idea in that regard.
With guix, you at least install things in a container.
sadly, guix also went the non-conda-route, so you could not use it as a conda replacement only :(
To be honest, mainly companies need that. personal users do not need that. And additionally companies are NOT restrained by governments not to exploit customers as much as possible.
So... i also see it as enslaving users. And tell me, for many private persons, where does this actually give them for PRIVATE persons, NOT companies a net benefit?
> This potential shouldn't prevent our inventing new kinds of tool.
Why do i see someone who wants to build an atomic bomb for shit and giggles using this argument, too? As hyperbole as my argument is, the argument given is not good here, as well.
The immutable linux people build tools, without building good tools which actually make it easier for private people at home to adapt a immutable linux to THEIR liking.
avoiding backdoors as a private person you always can only solve with having the hardware at your place, because hardware ALWAYS can have backdoors, because hardware vendors do not fix their shit.
From my point of view it ONLY gives control and possibilities to large organizations like governments and companies. which in turn use it to control citizens
Imagine you're using a program hosted on some cloud service S. You send packets over the network; gears churn; you get some results back. What are the problems with such a service? You have no idea what S is doing with your data. You incur latency, transmission time, and complexity costs using S remotely. You pay, one way or another, for the infrastructure running S. You can't use S offline.
Now imagine instead of S running on somebody else's computer over a network, you run S on your computer instead. Now, you can interact with S with zero latency, don't have to pay for S's infrastructure, and you can supervise S's interaction with the outside world.
But why would the author of S agree to let you run it? S might contain secrets. S might enforce business rules S's author is afraid you'll break. Ordinarily, S's authors wouldn't consider shipping you S instead of S's outputs.
However --- if S's author could run S on your computer in such a way that he could prove you haven't tampered with S or haven't observed its secrets, he can let you run S on your computer without giving up control over S. Attestation, secure enclaves, and other technologies create ways to distribute software that otherwise wouldn't exist. How many things are in the cloud solely to enforce access control? What if they didn't have to be?
Sure, in this deployment model, just like in the cloud world, you wouldn't be able to run a custom S: but so what? You don't get to run your custom S either way, and this way, relative to cloud deployment, you get better performance and even a little bit more control.
Also, the same thing works in reverse. You get to run your code remotely in a such a way that you can trust its remote execution just as much as you can trust that code executing on your own machine. There are tons of applications for this capability that we're not even imagining because, since the dawn of time, we've equated locality with trust and can now, in principle, decouple the two.
Yes, bad actors can use attestation technology to do all sorts of user-hostile things. You can wield any sufficiently useful tool in a harmful way: it's the utility itself that creates the potential for harm. This potential shouldn't prevent our inventing new kinds of tool.
To be honest, mainly companies need that. personal users do not need that. And additionally companies are NOT restrained by governments not to exploit customers as much as possible.
So... i also see it as enslaving users. And tell me, for many private persons, where does this actually give them for PRIVATE persons, NOT companies a net benefit?
NAT (in all its forms) is just a very convenient technology for many people and niche situations.
And adoption of IPv6 will be hindered as long as NAT is not a first class citizen.
And of course, mostly NAT should not be used as "firewall replacement". But what many firewall proponents forget here:
NON-IT People at home cannot run and manage a firewall (and proxies). For them, NAT is a convenient and mostly okayish replacements.
Another niche would be IP Packet Handling of VMs.
Regarding the 'protocol for the waves,' you'll need to play with modulation. That’s the fun part. In technical literature, there are many well-defined modulations (like AFSK or FSK) with clear suggested applications for low-SNR environments.
As for Android support, I have no idea. I understand that in this thread, 'free' sounds like 'freedom,' but freedom has a cost. The freedom of communication requires investment: in hardware, software, and the time to learn the physics of the environment.
because the fun thing is cool, but people want some usable...
It saddens me that people aren't willing to pay a pittance in cash (about $1 an hour) for entertainment. They're willing to spend their time, but not their money.
This isn't just buying a 100 episode box set, it applies to people complaining "I'd have to spend $10 on $streaming_service to watch that 5 hour miniseries, that's terrible" too.