> Most people don't do anything worth privacy protecting.
That may be true, but most people still benefit indirectly from the actions of the few who do have something to hide (e.g. protestors, journalists, whistleblowers).
If we want the masses to continue to benefit from the actions of those few, then we need to find a middle ground. Someplace where the masses are private enough that a truly private individual can hide among them without sticking out like a sore thumb. You don't need to hide, you just need to be able to hide.
I would say that statement comes out of people's ignorance not out of informed knowledge. For those that even do know feel helpless in the face of industry standard treatment of privacy.
I'm not who you asked, but I think that digital copyright has poisoned society and needs to go because to enforce it, you need a way to shut content off, so you need to build infrastructure that grants somebody censorship power. That's a high value target, and attracts the attention of precisely the people you'd rather not have censorship power.
The internet infrastructure that allows digital rights holders to protect their intellectual property also lends itself to things like billionaires owning media platforms so that they can influence public opinion: It's about protecting capabilities that third parties use to influence discourse at the expense of the users. If you reshaped the landscape to remove the chokepoints, there would be nothing for those billionaires to buy, and our technology wouldn't be amplifying cults of personality to the extent that it currently is (or rather, it would amplify based on personality, not ownership... an upgrade?).
We're living in a sort of influence aristocracy which is protected by the seats of control that were created to protect digital copyright.
How would you otherwise protect the people who invest their time and resources into building digital tools and products? Without digital copyright isn't it open season on any digital idea since it can just be stolen?
My primary argument is that however bad it would be if content creators were left unprotected, the sort of platform abuse that we're seeing today is even worse. Happy artists are important, information symmetry (re: markets and re: democracy) is more important.
But yeah, suppose we've made that switch, and now we want a new way to encourage content. I'd propose that we build attribution into our protocols. Many years ago there was controversy over "reaction" videos on youtube. They were being taken down because half of the screen was copyrighted (while the other half included somebody seeing it for the first time).
Rather than having the content exist as a single thing that either is allowed to be public or is not, I'd say that the fight should converge on how much credit was given to the person who put together the reaction video (some), and how much credit goes to the creator of the reacted-to content (more).
When I say "credit" I mean that as you browse your browser would keep track of which content you consume, and which parts of it are attributed to which people (or maybe these are bank accounts or crypto addresses or whatever). Part of paying for internet access would be allocating some fixed amount, $15/mo say... for content. At the end of the month, you'd send the $15 to the creators of your content (split up based on your consumption) and send the ISP proof that you've done so. Otherwise, your ISP collects the $15 and it goes to some nonprofit dedicated to mediating credit disputes and to educating creators on how to ensure that they do in fact get credit for their work.
This way there's no incentive to not pay for the content you're consuming: you the consumer are out the money either way. Also, the browser doesn't have to share the consumption history with the ISP... in order to meet their regulatory burden, the ISP need only see proof that you have done so. Lastly, unallocated money goes towards ensuring that future money is indeed allocated to a content creator, so it's a negative feedback loop which would hopefully converge on a state where most people participate in funding their creators.
If ISP's don't cooperate, we tax the bejeezus out of them and remove their protections re: who gets to use which buried cables such that new ISP's emerge that will cooperate.
Are you actually talking about software patents, not digital copyright? Software patents protect ideas (i.e. algorithms), software copyright protects implementations (i.e. source code and binaries).
Natural keys are often the best you can do if you're trying to be partition tolerant.
With surrogate keys you end up with duplicate entities whenever a partition heals (supposing the entity appeared to both partitions while they were still separate).
I imagine a social media site full of bots chatting about nonsense. Hidden in the nonsense are humans chatting about different nonsense. This way, server costs get paid for by advertisers, but its really only bots that see the ads anyway.
Unfortunately I beg to differ. I worked for several companies where we the management clearly saw that the results were very poor (for Facebook ads, for example) but continued to invest because there is a defined budget for it and so on. It was like this last year and 20 years ago.
these companies should be outcompeted by firms that don't blow a million dollars a month paying out to click fraudsters but alas the market is not perfectly competitive
is it a cargo cult? it works for coca cola so maybe if we just spend a little more we'll see returns...
I'm not really concerned with whether it would work out in a way that was beneficial for the ad network or their customers. Either they figure out a way to make it work such that they continue to be a useful pipe, or they don't and then maybe they'll have to shut down and find something more productive to do with their time. We'll have done the public a service either way.
I'm not so worried about my disciplined coworker who just wants to help. If we were all reviewing his code I'd agree with you.
The people I want to help are those who are unknowingly reviewing malicious commits, and I think that declarative configuration languages have a part to play there.
This is solved in tools like Pulumi by having a declarative and auditable build artifact as an intermediate step that can be diffed. This seems to solve a lot of the security issues (and is generally a good idea anyway).
Some of the oddities of the nix language are pretty useful for its domain. Recursive attribute sets, for instance, save a lot of headaches if you're trying to have only a single source of truth. Do you feel like these translate to typescript nicely?
As somebody who knows nix but doesn't know typescript, I found myself looking for a rosetta stone page where I could look at two chunks of code that do the same thing, but in separate languages. This would let me use the familiar language to scrutinize the other.
I wouldn't normally ask for such a thing, but if you're putting "Nix-like" in the title then maybe it might be worth adding a comparison page to the docs.
I think the lack of true laziness will be a big performance problem for a large build graph.
On the other hand the monolithic nature of the nixpkgs package set is one of the authors gripes with nix, so performance at that scale may be a non-goal.
I'd definitely like to have good performance even for large build graphs! I'm hoping the laziness exists "where it counts". To walk through an example, if you build your backend, and your backend calls the function `postgres()`, and that calls `openssl()`, and THAT calls `gcc()`, etc., etc., each function is basically building an object to represent its chunk of the build graph (each function returns a "recipe"). Nothing gets built until that object gets returned from the top-level function and the runtime does something with it
In other words, the eager part is basically constructing the build graph. Maybe I'm wrong but I don't that this would necessarily be slower than the lazy version. In practice the most complex build graph I've made is basically the full chain of Linux From Scratch builds (that's the basis for my toolchain currently), and I think that takes about 400-500ms to evaluate. It's about 160 build steps, so it's not _simple_ but I know build graphs can also get a lot more complex, so I'll just have to keep an eye on performance as I start to get into more and more complex builds
Maybe I'm missing something but intuitively I'd expect this approach to be fairly efficient-- as long as build scripts only call these functions when they're used as part of the build graph
I think it really depends on your definition of "large". I don't think strict eval + full build graph can scale to something the size of nixpkgs, for example.
I mentioned in another comment that this is why Bazel uses simple strings to form dependencies on other targets. That way Bazel can manage the laziness and only evaluate what is needed without needing to use or invent a language with lazy evaluation.
But that is also the big downside (in my opinion) - the full build graph necessarily can't exist purely in starlark (at least for Google-scale projects) which increases complexity of the tool overall.
Edit: I'd like to add, though, that I think it's perfectly fine to not scale to Google scale or nixpkgs scale! Many many projects could still benefit from a great build tool.
Honestly, I think the "stringly-typed targets" thing isn't too bad, having used Buck2 quite a bit, and being a Nix user for 10+ years. If anything, it's a small price to pay for some of the other smart things you get in return, like the far more fine-grained action graph and the tooling around BUILD files like querying. One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to meaningfully evaluate or even parse correctly, so you can still build other subsets of the tree even when things are broken; at ridiculous-scale it's nearly impossible to guarantee that, and it's something Nix does worse IMO since evaluation of the full nixpkgs tree is slow as hell in my experience but a requirement because a single eval error in the tree stops you dead in your tracks.
Also, no matter how much I might not like it as a language nerd, I think Starlark is simply far more "familiar" for your-average-bear than the Nix language is, which matters quite a bit? It might be more complex in some dimension, but the problem space is fundamentally complex I think. So other factors like how approachable the language is matters. (And at least in Buck2, you can use MyPy style typing annotations, thank God.)
> One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to meaningfully evaluate or even parse correctly, so you can still build other subsets of the tree even when things are broken; at ridiculous-scale it's nearly impossible to guarantee that, and it's something Nix does worse IMO since evaluation of the full nixpkgs tree is slow as hell in my experience but a requirement because a single eval error in the tree stops you dead in your tracks.
I think you get more or less the same property with Nix. You can have all kinds of errors, even certain syntax errors in the same file, but if they are unneeded for the current evaluation, they won't cause any problems.
As for language familiarity/approachability - this will always be a matter of opinion, but I personally don't think it makes sense to optimize for the casual contributor. Plenty of people know python, but I never see casuals making anything besides trivial changes to bazel build files. I don't think they gain anything by familiarity with python, they could very well copy paste nix or any other language. And if they get in to trouble, they will call in the experts.
I've been asked about overrides and attributes a lot! That was one of the sacrifices I had to make to go with a more traditional language, so it's definitely a negative point compared to Nix. That said, I'm hoping to have some conventions and features that will cover _most_ of the use-cases that overrides give you, but that's definitely still future work at this point and I probably won't be able to cover everything overrides do
And yep, I think having a "Brioche for Nix users" guide makes a lot of sense, although it's not the first time that question so I'll probably stand up a first-pass version of it sooner rather than later (my Nix skills are also pretty rusty-- I'll need to brush up a bit first before I write it!)
I work with Apache Airflow. But lead my sister to believe for a time that I had begun to transition to a career somehow related to HVAC and solving the problems associated with "patchy" airflow in certain places.
Also, roads and tires are made out of the goopy parts of oil, so their manufacture impacts the price of the fuel parts of oil. Your EV's roads and tires make it cheaper for others to not buy an EV.
Food and cars are things you can touch. Health isn't. Markets work well for things you can touch, and poorly for things you can't.
It's just the natural limits to our concept of property at play. Maybe everybody knows what you mean if you say that you're going to go down the street and buy yourself a surgery, but nobody thinks it's a natural way to talk about that sort of thing.
That may be true, but most people still benefit indirectly from the actions of the few who do have something to hide (e.g. protestors, journalists, whistleblowers).
If we want the masses to continue to benefit from the actions of those few, then we need to find a middle ground. Someplace where the masses are private enough that a truly private individual can hide among them without sticking out like a sore thumb. You don't need to hide, you just need to be able to hide.
reply