Hacker Newsnew | past | comments | ask | show | jobs | submit | more parminya's commentslogin

I generally agree that the documentation is a problem. A lot of the code is commented, so if you can find a package in nixpkgs that is using the same language, you can usually do some copypaste, somehow find the function definition it's referencing, and then it's not so hard to make the changes to package your new package. But "somehow find the function definition it's referencing" is not always as easy as it sounds... I think it's the only way to learn though. The documentation just isn't up to the level it needs to be to be self-sufficient.

As for flakes, they're not that big a change. There's some entry point which you have to learn about - a special file (flake.nix) that defines inputs and outputs according to some predefined structure. But the output leafs are just normal nix code - it's just that there's some builtins that can't be used because they do side effects at runtime. But that's less important than it sounds, because if you're using nixpkgs (as a library/input or as a source for copypasting) then it's flake-safe.


This is generally true, but I have yet to successfully make a nix overlay for any haskell package not already in nixpkgs. I can't make heads-nor-tails of how the haskell packaging works, other than forking nixpkgs and rerunning the scripts that generate the packages from cabal.



You say nothing seriously false, but perhaps depending on things like NodeJS just inherently means your software is going to be poor quality. If that is true, then both you and the PP are probably right. I tend to think software quality will be higher if you depend on a third-party collection (such as so-called Linux distributions) than a second-party aggregation (such as NPM).


Even the distributions have a hard time with the NodeJS environment and its relentless pace - and the more software gets written in JS the worse. When e.g. software A depends on library X@1.0 and software B on library X@1.1, and X has done breaking changes, what should a distribution do?

Hard forks in the package name (e.g. libnodejs-x-1.0 and libnodejs-x-1.1) are one option, but blow up the repository package count and introduce maintenance liability for the 1.0 version. Manually patching A to adapt to the changes in X works, but is a hell of a lot of work and not always possible (e.g. with too radical changes), not to mention if the work should be upstreamed, then licensing issues or code quality crop up easily which means yet more work. Dropping either A or B also works, but users will complain. And finally, vendoring in dependencies works also, but wastes a lot of disk space and risks security issues going unpatched.

And that's just for final software packages. Dependency trees of six or ten levels deep and final counts in the five digits are no rarity in an average NodeJS application.

Importing even the bare minimum introduces an awful lot of work and responsibility to distributions.


I don't think tbody is really obscure to anyone writing with DOM. You can't embed a tr into a table: it has to be in a thead/tbody/tfoot. If you're writing HTML it's fine, the browser does it for you. But if you're writing DOM (directly or indirectly with e.g. React) you need to use the tbody tag or else it won't do you what you wanted.


Fun fact: `table > tr` is actually valid HTML.

> […] followed by either zero or more tbody elements or one or more tr elements […]

https://html.spec.whatwg.org/multipage/tables.html#the-table..., the table element, content model.

Sure, the HTML syntax will imply it (and https://html.spec.whatwg.org/multipage/syntax.html#element-r... mentions this, how in HTML syntax `table > tr` is invalid), but this means that in XML syntax <table><tr><td/></tr></table> is actually valid.

I believe XHTML compatibility is the reason for this. But I have no real idea quite why XHTML 1.0 decided to allow (tbody+|tr+) (basically a mixture of HTML 3.2 and HTML 4) rather than tbody+ like HTML 4.


I think they died well before responsive became a concern. Their heyday was really the time before not just CSS but even tables, at which time they were the only way to have links positioned in space rather than in flowing text. I don't think anyone liked imagemaps - it's just that there was no alternative.

But their limitations were massive. Chiefly, in a period when dialup internet was becoming more common, an image map meant that before a user could interact with your website, they had to wait for a very slow download of a very large image that contained mostly text. You couldn't interact with them any more - no ability to select the text in them, or perhaps the reader had a different color/font preference? Tough luck.

When tables came out, they began to face competition, but they weren't defeated. Aside from table-first designs that mixed images and text, you could mostly do without imagemaps by cutting the image up, eliminating table borders/cellpadding/cellspacing and making careful use of colspan and rowspan, with a part of the image in each cell. This had most of the same user-side problems as imagemaps, but was easier for many people to maintain (I'm not sure quite why: I assume some people have trouble with thinking in terms of x/y coordinates and regions).

CSS thoroughly destroyed them. Everything an image map could do, tables+CSS and eventually CSS could do better. This was still ages before responsive became a concern, at a time when webpage maintainers would assume you used an 800x600 or 1024x768 screen with a maximized window and just ignore everyone who didn't match that.

Nowadays, any time an image map might look like the solution, the actual solution is SVG, which gives you everything an image map had but is moreover correct.


> before a user could interact with your website, they had to wait for a very slow download of a very large image that contained mostly text

Back then we also had the lowsrc attribute for images, so that large image should have been preceded by a much smaller 1-bit version.


> A strong argument for independent central bankers.

It's a weird sort of thing. At one level it's easy, just elect politicians who respect independent central banks. But it's the politicians from whom the central banks are independent, so can they really be independent if their independence depends on the people who they're independent from?

Erdogan started his career with relatively independent central bankers, but since they made decisions he didn't like, he replaced them with cronies. Erdogan was also able to change the constitution to reflect his preferences, so it isn't an argument for entrenched independent central bankers either - a person who can get the constitution changed, but who doesn't get rid of the independence of the central bank is choosing that.

We can go back and say it's an argument for electing politicians who respect the independence of central banks, but it's something like an argument that says we should elect good economic managers: if you could reliably get good economic managers, it doesn't matter if you have independent central banks, and it doesn't matter if you have independent central banks if you have bad economic managers. And on the other hand, most voters just aren't going to consider the independence of central banks when voting.

With Erdogan, it doesn't matter how the economic management is structured: you're going to get low interest rates and high inflation rates and generally spook the market. Your goal has to be not to get Erdogan, over and above any argument for central bank independence.

Really, all we're left with is the political position that good economic management is better with central bank independence - a position Erdogan fundamentally disagrees with.

It's all the same with Pierre Poilievre in Canada (currently leader of the Conservative Party and the Official Opposition), who stated he wanted to fire the chair of the Bank of Canada because he didn't agree with their decisions. Once you do that, you don't have an independent central bank any more. So the only way for Canada to retain central bank independence is not to vote for Poilievre. But in Canada as in Turkiye, the central bank's independence from politicians would be dependent on politicians i.e. there wouldn't actually be central bank independence.

At the end of the day, "central bank independence" only exists if major political players in government and opposition agrees to it. Surely they should look at this lesson, and I think the lesson of recent weeks in the UK too. They both tell you that governments are up against limitations in what they can do and that the governments who respect those constraints will govern their countries better than the ones who don't, even when they make stupid decisions.

I think I would be greatly relieved if there was a different phrase, one that tells you what we mean, rather than something that is impossible at the time it is most needed.


Democracy creates buy-in and legitimacy, and requires good ideas to be sold to the people rather than imposed on them. There is additional evidence that compulsory voting adds to this legitimacy (in ways that may be freedom-harming, if that matters to you - in particular, some people find evidence that Australia can typically impose stricter rules than other democracies because of compulsory voting). Some of this might go against the American tradition of democracy (which exists to help entrench freedom) but it is compatible with the Australian-British tradition of democracy (which is the goal in itself).

Democracy acts as a circuit-breaker for entrenched inefficient resource allocation. For instance, if there was no usable legislative process, but only an executive and a precedent-based judicial system, markets would generally be free, but this would allow the intergenerational accumulation of capital/wealth until some people have almost total power, and some people are essentially serfs. But in democracy, the mere potential for the mass of people to vote themselves wealth limits the incentives to aggressively accumulate capital/wealth. For instance, if the rich want their property rights to be respected, they need to make sure that the mass of the country has enough property to also want protection. And if that potential doesn't work, it can actually be used and new taxes and rules can be introduced that distribute wealth more efficiently.

As you can see, some might not agree with your conclusion that "there's a good case for limiting democratically elected politicians['] influence over the economy, by enshrining private property rights and the independence of the central bank in the constitution". By asking the question you did, you first presumed that democracy was inefficient and on that basis drew a conclusion, but then asked how a person who thought democracy improves efficiency would argue for the conclusion whose premises they disagree with.


Just use each finger as a binary digit, open or cloned, and you can get to 1023. If you're really struggling to count you might add your eyes, elbows or and knees and get to 2^16 - 1. That should be enough for anyone.


I don't think your concerns about 7 or 14 year terms are actually necessary:

> However, you do need to protect individuals from corporations.

This is generally true, so much so that I think the only relevant action would need to be general, to protect individuals from corporations generally. Creators would benefit from protection regardless of whether the term is changed.

> If I submit a book to a publisher, they say "no", then they hold it for 14 years and decide to publish it ... I'd still want to be protected.

Presumably a much greater proportion of work would be prepaid (via mechanisms like the built-in ads on youtube videos) or self-published. Although they continue to add value, publishers are much less necessary at the moment than previously (as we can see from independent podcasts). The marketplace and output might be completely different if there are short terms, but it will not lead to a collapse in production or a failure to remunerate artists.

In any case, the authors of copyright material are not presently engaged in free and equal relations with corporations. If nothing else, a corporation is generally able to sue you, whereas you're generally not able to sue a corporation. And a corporation will write contracts that regularly get tested in courts and get tweaked and improved, whereas you will rarely write contracts and you will rarely have opportunity to improve them based on problems.

> Visual artists, painters say, often become popular later in their career; should commercial interests be able to exploit that lag to sell the person's earlier work without the person getting reward?

This doesn't happen because their work obtains some additional quality through the passage of time, as though it were a wine ageing in oak. It happens because of the reputation of the artist; by buying the work, the owner has some kind of a relationship with a well reputed person. If anyone is selling a print, the print that is personally authorised by the artist will have a higher value. Therefore, I would suppose this isn't a problem that needs to be fixed.

None of this means that everything would continue just fine. Reducing copyright to a few years would be revolutionary. It would result in actual cultural changes. For instance, right now you can use copyright to create artificial scarcity that lasts essentially forever. With a seven year copyright, the artificial scarcity only lasts a few years, so you need to make the most of it. That means that oldness is free and recency is expensive - a reversal of the current system (where oldness is expensive, because it costs more to get something that last a long time, but recency is cheap)


> In any case, the authors of copyright material are not presently engaged in free and equal relations with corporations. If nothing else, a corporation is generally able to sue you, whereas you're generally not able to sue a corporation. And a corporation will write contracts that regularly get tested in courts and get tweaked and improved, whereas you will rarely write contracts and you will rarely have opportunity to improve them based on problems.

I'm sorry to say this, but this is (from my personal experience as a one man company dealing with corporations) complete and utter baloney. Including suing them.

I wrote my own contracts, and lawyers who looked at them later said they were pretty good, though I probably would have been smarter to use the lawyers in the first place.

There is NO REASON WHATSOEVER that would force you to accept terms from a corporation that YOU DON'T LIKE.

Just say "NO".

And yes, I have successfully sued a major corporation you've all heard of for cheating me out of 6 figures of royalties. I won't name the company because this was settled long ago. It was so blatant that my lawyer took it on contingency.

Ordinary individuals can and do successfully sue major corporations all the time. All you need is a solid case.


> Uniquely complaining about PORTUGAL being unaffordable for the PORTUGUESE is such a Portuguese mentality, I can't even.

I love this complaint. It's so perfectly a demonstrations of itself. It's somehow as if, suffering a problem that someone else suffers from, means you're not allowed to even discuss it. It's also hardly unique to Portugal. Most countries discuss domestic politics in terms of the country, because they have say over the policy of non-domestic territories. (Usually - colonial empires excepted.)


If the web browser is governing the passwords you can and can't have, and forcing you to have unmemorisable passwords, you're better off rethinking the whole thing. For instance, it probably makes more sense to ask the web browser to generate keypairs rather than passwords if we know the passwords cannot possibly be memorised.


I don't reuse passwords, or use a password manager. I just have a system for remembering which password to use for each website, and maintain a list of hints. And I have a pretty terrible memory. But having had the password I used to re-use across a few (non- critical) sites show up on haveibeenpwned it's what works best for me.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: