Look at the installation instructions. <https://docs.joinpeertube.org/install/any-os> They are very onerous. Yes, I've seen worse, but the ratio between manual labour in service of non-essential complexity and the provided value is still quite bad.
Peertube covers the enterprise use case, but makes unreasonable demands from hobbyists, single users, tinkerers. Kids, gather around and learn from the Peertube design mistakes that an experienced and well-meaning software designer would refuse to subject his users/operators to. Why is this important? Because the number of hobbyist operators is much greater than the number of enterprise operators, given the intended target audience of people who are interested in decentralisation and federation. Peertube engineers and product managers should sit down with the intention to make a smart market move, and expend the next half month of effort to optimise for the majority of operators who make up the long tail, not the minority, so that hurdles to entry are demolished and the stated goal shown on the homepage of "community-owned" becomes attainable for many more people than is the case right now. The resulting network effect would be tremendous.
1. Packaging. Peertube is not packaged by the major players. <https://repology.org/project/peertube/versions> Real-life experience shows that this is almost always because of a circumstance which frustrates a distro packager. Other NPM-conformant libraries and software are packaged nearly automatically, there is good support in the distros to create specfile/RPM package, control file/Deb package, etc. from an Nodejs library tarball with just one command. Peertube must investigate why it is so exceptional and difficult to package and demolish the hurdles.
2. Configuration. Peertube must as the installation step make effective an usable configuration that has some sensible defaults, or perhaps auto-configure at install time or run time. A user should be able to install the software (from a distro package, or a git checkout/unpacked tarball and build step), run it, and immediately use it. It is okay when some features are not working until configured. It is not okay for a software to refuse to work altogether until each and every operator spends time and brain power to figure out what are essential configuration options and what are not, and make decisions about them. The reason why I say it is not okay is because this is a clear abdication of responsibility from the Peertube software devs and an externalising of mental burdens onto the many Peertube operators.
3. Database. Peertube should work with Sqlite by default. An enterprise user can configure PostgreSQL additionally when the need arises.
4. Web server. Peertube should work with the Node.js Web server (possibly express.js or a work-alike) by default. An enterprise user can configure Nginx additionally when the need arises.
5. Cache. Peertube should work with a simple file system cache or no cache at all by default. An enterprise user can configure Redis additionally when the need arises.
Not so. The consideration should include the fact that when a child has been spawn camped by school, family and society at large to implant the idea that tertiary education is required to participate in society and without a degree one amounts to nothing, as is often the case, then it indeed is a failure of systematic nature and it would be not fair to put the blame on the now young adult's shoulders alone.
> Meaning it can be learned. Trained. […] In fact, a college education is a great way to increase your IQ.
You make this argument on the assumption that the effect is causal. But in reality one cannot distinguish whether education raises IQ or whether people with higher IQs stay longer in college.
That's the critique, yes. If I put this grammar into a known good parser, it just works. I have to repeat this to hammer the point home.
A user should not have to waste time to find work-arounds for the undocumented limitations. Since there are many more limitations than just the one example I showed, you should realise that there is not much value explaining the particular limitations to me; all the limitations and the required work-around steps should rather go into the Janet documentation so that all users can see them and make use of them. But that's still a crappy developer experience, I would rather see Janet simply adopt a parser that is free of this kind of limitations.
> can always be fixed by a simple local change
I sceptical of that. I claim once the grammar is of the size required to model real-world problems, say about dozens of production rules, fixes become complex, wide-scoped. In the spirit of HN curiosity, I am willing to cooperate with you by conducting an experiment that is designed to change my mind. I would show a grammar that is of the type which is in common use everywhere, and you would apply the fixes to make it work in Janet/PEG, and then we examine whether the changes are always simple and local. Are you willing?
> [PEG grammar in Tree-sitter]
That reads rather bizarre to me because you describe the opposite direction. I have not had that train of thought because in all of my experience and those of the people I know it has always been the case that one receives a grammar that is of the type which is in common use everywhere. And when we try to express it in PEG, it does not work at all, no one knows what to do to make it work, experts who might help cannot be found, and the solution (after wasting a lot of time) is to either give up or try a different parser.
As an aside, I have not examined Tree-sitter yet, and its documentation does not tell me the information I need, so I cannot put it into the category of known good parsers.
Many. I don't have enough room on HN to show a representative sample of the shortcomings. Read the relevant literature or converse with an LLM to learn more.
This almost trivial grammar works without any problem in known good parsers. If you want to try out grammars in the wild in Janet, it is nearly guaranteed that they are complex enough for peg to shit itself.
Came here for this comment. Janet would score positively in my mind if the evolutionary dead-end PEG were replaced with a grammar parser that is known to work under all circumstances.
Because society is full of dickheads? In a just world, it would be legal for a policeman to bludgeon anyone who does not respect a user agent's <https://en.wikipedia.org/wiki/Do_Not_Track> setting. Second offence, hang them from the flagpole in front of the parliament building. The problem would disappear over night.
This answer that is both so stupendously confident and wrong is only possible if you in actuality decided to not read and understand how this problem is solved in Perl.
You seem to be under the impression that adding new syntax necessarily breaks existing code. But that just isn't true. If you can't fathom how it's done, then look at the use VERSION statement in Perl.
Under the circumstance that the primary and secondary education levels have failed to adequately prepare a student for tertiary level, I think your idea would be unfair.
Do you have an actual argument? Shaming tactics are ineffective on HN.
Reality check: in most countries, if you made a public demand of effectively depriving the disabled of the proper care they want and deserve, they would regard you as an inhumane monster, and the education ministry would refer you to state prosecution for violating the constitution.
You were downvoted as a punishment because you made a retarded argument and HN users saw fit to not engage with words.
No billionaire is forced to break up a public company to pay taxes, the same as no average Joe is forced to sell his clothes to pay taxes. The idea in common is that if one knows that one must have cash at the end of the fiscal year, then one sets aside the money and simply avoids buying clothes or investing in assets.
This VB feature existed to accommodate programmers coming from the DOS based QB IDE who were used to the one function per screen view there. To my sensibilities, it does not make much sense with the advent of high-resolution desktop environments.
Peertube covers the enterprise use case, but makes unreasonable demands from hobbyists, single users, tinkerers. Kids, gather around and learn from the Peertube design mistakes that an experienced and well-meaning software designer would refuse to subject his users/operators to. Why is this important? Because the number of hobbyist operators is much greater than the number of enterprise operators, given the intended target audience of people who are interested in decentralisation and federation. Peertube engineers and product managers should sit down with the intention to make a smart market move, and expend the next half month of effort to optimise for the majority of operators who make up the long tail, not the minority, so that hurdles to entry are demolished and the stated goal shown on the homepage of "community-owned" becomes attainable for many more people than is the case right now. The resulting network effect would be tremendous.
1. Packaging. Peertube is not packaged by the major players. <https://repology.org/project/peertube/versions> Real-life experience shows that this is almost always because of a circumstance which frustrates a distro packager. Other NPM-conformant libraries and software are packaged nearly automatically, there is good support in the distros to create specfile/RPM package, control file/Deb package, etc. from an Nodejs library tarball with just one command. Peertube must investigate why it is so exceptional and difficult to package and demolish the hurdles.
2. Configuration. Peertube must as the installation step make effective an usable configuration that has some sensible defaults, or perhaps auto-configure at install time or run time. A user should be able to install the software (from a distro package, or a git checkout/unpacked tarball and build step), run it, and immediately use it. It is okay when some features are not working until configured. It is not okay for a software to refuse to work altogether until each and every operator spends time and brain power to figure out what are essential configuration options and what are not, and make decisions about them. The reason why I say it is not okay is because this is a clear abdication of responsibility from the Peertube software devs and an externalising of mental burdens onto the many Peertube operators.
3. Database. Peertube should work with Sqlite by default. An enterprise user can configure PostgreSQL additionally when the need arises.
4. Web server. Peertube should work with the Node.js Web server (possibly express.js or a work-alike) by default. An enterprise user can configure Nginx additionally when the need arises.
5. Cache. Peertube should work with a simple file system cache or no cache at all by default. An enterprise user can configure Redis additionally when the need arises.