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

I can’t quite tell if this is satire! You may be familiar with a small startup (https://en.m.wikipedia.org/wiki/Netflix) in the business of buying a million DVDs and continuously renting them out on demand to make something resembling a video rental store.


I'm pretty sure that even video rentals were not allowed without the consent of the copyright holder. The videotapes or DVDs you could buy at retail weren't licensed for commercial use.

Lending them without cost, like a library, I don't think they could stop you. But commercially renting out the physical media wasn't an automatic right, as far as I know.


In addition to the DoS aspect mentioned in a sibling comment, the primary reason you would do this is to avoid constraining the implementation. If you want to change the design to improve performance, for example, being forced to match the implicit ordering of the old implementation may be very difficult.

It certainly may be useful to define an specific ordering. Maps ordered by insertion time and maps ordered by key order are fairly common. But maps with these constraints probably won't be as fast as those with arbitrary ordering, so there is a trade-off decision to be made. A map constrained to the arbitrary ordering of the initial implementation is the worst of both worlds: difficult to make faster despite not having a particularly useful ordering.

As a concrete example, I am currently in the middle of rewriting Go's map implementation to use a more efficient design (https://go.dev/issue/54766). If Go hadn't randomized map iteration order this work would likely be impossible. It is unlikely we could completely change the design while keeping iteration order identical to the old implementation (assuming we want the new version to be faster at least).


Cool! Yes, that’s been our experience in Java as well. The randomized order of unmodifiable Set and Map (from `Set.of` and `Map.of`) have enabled us to make optimizations to the internals mostly with impunity. We’ve done so twice since their introduction and we might do so again.


It is just a TLD. https://get.new/


Thanks for the link. I discovered that you can create new repo or gist on github using

repo.new

gist.new

That's very handy and useful.


I think the closest analog to this is digital services getting worse rather than more expensive. For example, recently rather than increasing the price of Amazon Prime Video, the price has remained the same, but the product is worse (now has ads).

That said, I don’t think this bill would target something like that, as it clearly discusses the “size” and “amount” of a product.


I agree, but it would be a total quagmire if they allowed it to extend to digital services and other non-traditional uses of the term. Seems like it would have to relate to buying typical consumer commodity goods only or things would get weird.


When I was a kid, a season was 26 episodes, although they did have fill up and clip show episodes. Nowadays you're lucky to get 6 episodes, but sometimes these are really good episodes.


Episode runtimes are up to the full hour thanks to streaming and lack of ads (the golden age is probably passing sadly) instead of being 20 minutes with room for 10 minutes of ads to fill the 30minute broadcast slot.


Q1 earnings (https://s25.q4cdn.com/442043304/files/doc_financials/2023/q1...) says 383M daily active users and $1.3B in costs (including sales, administrative, etc), for ~$3.50/user/quarter or ~$14/user/year. So far above $2.50/user/year. Even just using cost of revenue is ~$4.50/user/year.


I clarified that I meant just infrastructure costs, and posted the source.

Even so - what's $4.50 per user per year - 40 minutes of minimum wage work? 45 seconds of a lawyer's time?

For sending, and processing, and receiving GBs and GBs of video?

For (not even) this cost, we give up control of political narratives? We let people like Huffman and Musk and Zuckerberg control what we get to see?

They take money from tinpot dictators and a selection box of wealthy grifters. We let our parents and grandparents get taken advantage of by every scam artist on the planet with a few dollars. Why? To save $4.50 a year?


See https://news.ycombinator.com/item?id=34097179. A comm is limited to 64 bytes, so I don't think it is possible to fit a long enough comm to match the full regexp.


Right, it's not a security problem on its own, but it can make the regex not match at all causing jc to return an error. So jc suffers from the parsing bug mentioned in the post.

[edit:] In order to get jc to return an error one has to actually read the regex. Here is a file name that gets it to return an error:

  bad) S 1 2 3 4 5


It doesn't look like jc suffers from this bug since the regex match is greedy:

    % echo '2001 (my (file) with) S 1888 2001 1888 34816 2001 4202496 428 0 0 0 0 0 0 0 20 0 1 0 75513 115900416 297 18446744073709551615 4194304 5100612 140737020052256 140737020050904 140096699233308 0 65536 4 65538 18446744072034584486 0 0 17 0 0 0 0 0 0 7200240 7236240 35389440 140737020057179 140737020057223 140737020057223 140737020059606 0' | jc --proc

    {"pid":2001,"comm":"my (file) with","state":"S","ppid":1888,"pgrp":2001,"session":1888,"tty_nr":34816,"tpg_id":2001,"flags":4202496,"minflt":428,"cminflt":0,"majflt":0,"cmajflt":0,"utime":0,"stime":0,"cutime":0,"cstime":0,"priority":20,"nice":0,"num_threads":1,"itrealvalue":0,"starttime":75513,"vsize":115900416,"rss":297,"rsslim":18446744073709551615,"startcode":4194304,"endcode":5100612,"startstack":140737020052256,"kstkeep":140737020050904,"kstkeip":140096699233308,"signal":0,"blocked":65536,"sigignore":4,"sigcatch":65538,"wchan":18446744072034584486,"nswap":0,"cnswap":0,"exit_signal":17,"processor":0,"rt_priority":0,"policy":0,"delayacct_blkio_ticks":0,"guest_time":0,"cguest_time":0,"start_data":7200240,"end_data":7236240,"start_brk":35389440,"arg_start":140737020057179,"arg_end":140737020057223,"env_start":140737020057223,"env_end":140737020059606,"exit_code":0,"state_pretty":"Sleeping in an interruptible wait"}
Edit: looks like I can tighten up the signature matching regex for the "magic" syntax per the issue found above. The greedy regex matching for the parser does seem to work fine, though.


Interesting - the proc-pid-parser actually parses that file name just fine:

    $ echo '2001 (bad) S 1 2 3 4 5) S 1888 2001 1888 34816 2001 4202496 428 0 0 0 0 0 0 0 20 0 1 0 75513 115900416 297 18446744073709551615 4194304 5100612 140737020052256 140737020050904 140096699233308 0 65536 4 65538 18446744072034584486 0 0 17 0 0 0 0 0 0 7200240 7236240 35389440 140737020057179 140737020057223 140737020057223 140737020059606 0' | jc --proc-pid-stat

    {"pid":2001,"comm":"bad) S 1 2 3 4 5","state":"S","ppid":1888,"pgrp":2001,"session":1888,"tty_nr":34816,"tpg_id":2001,"flags":4202496,"minflt":428,"cminflt":0,"majflt":0,"cmajflt":0,"utime":0,"stime":0,"cutime":0,"cstime":0,"priority":20,"nice":0,"num_threads":1,"itrealvalue":0,"starttime":75513,"vsize":115900416,"rss":297,"rsslim":18446744073709551615,"startcode":4194304,"endcode":5100612,"startstack":140737020052256,"kstkeep":140737020050904,"kstkeip":140096699233308,"signal":0,"blocked":65536,"sigignore":4,"sigcatch":65538,"wchan":18446744072034584486,"nswap":0,"cnswap":0,"exit_signal":17,"processor":0,"rt_priority":0,"policy":0,"delayacct_blkio_ticks":0,"guest_time":0,"cguest_time":0,"start_data":7200240,"end_data":7236240,"start_brk":35389440,"arg_start":140737020057179,"arg_end":140737020057223,"env_start":140737020057223,"env_end":140737020059606,"exit_code":0,"state_pretty":"Sleeping in an interruptible wait"}
But the "magic" signature doesn't recognize it:

    $ echo '2001 (bad) S 1 2 3 4 5) S 1888 2001 1888 34816 2001 4202496 428 0 0 0 0 0 0 0 20 0 1 0 75513 115900416 297 18446744073709551615 4194304 5100612 140737020052256 140737020050904 140096699233308 0 65536 4 65538 18446744072034584486 0 0 17 0 0 0 0 0 0 7200240 7236240 35389440 140737020057179 140737020057223 140737020057223 140737020059606 0' | jc --proc             
    jc:  Error - Parser issue with proc:
                 ParseError: Proc file could not be identified.
                 ...
I can fix the "magic" signature (regex) to account for such cases.


Neat! Your parser [1] almost has a similar issue because a comm could contain parenthesis, e.g., `foo) R 123 456`. But since a comm is limited to 64 bytes, I don't think it is possible to fit a fully matching string inside of the comm before the closing parent after the comm, which would thus make your regexp fail to match.

[1] https://github.com/kellyjonbrazil/jc/blob/master/jc/parsers/...


I’m not familiar with Upsource, but what you describe sounds somewhat like the Gerrit review process. Each commit is reviewed individually, but sending multiple dependent commits for review is supported as well. It is technically possible for a coworker to build on top of your unsubmitted changes (by checking out your commits and adding more on top). However this process gets somewhat painful if the coworker updates their commits, which would require you to do a convoluted rebase.


I played with Upsource back when it was their "static-analysis in the cloud," and it actually was cool, but holy hell it was a beast to get up and running, and (just like Qodana that they're trying now) the static analysis was(is?) indescribably hard to configure correctly to get meaningful results

I've heard great things about Gerrit, but it also seems like one of those "strongly opinionated, mailing-list based" review systems, and trying to lobby for such a thing in the GitHub/GitLab web based world is practically a non-starter in my experience


Gerrit is pretty strongly opinionated, but it is not mailing-list based. Review notifications are sent via email, but otherwise everything needs to be done via the web UI (or other tool using the API).


Kind of.

If configured you can send your review by emails https://gerrit-review.googlesource.com/Documentation/intro-u...

If you get the an email you can read it from your mail client, retrieve the change from Gerrit over git (git fetch gerrit.example.org refs/changes/45/12345,8 && git checkout FETCH_HEAD), address the review and send back to Gerrit (git push gerrit.example.org HEAD:refs/for/main). Though to mark the review comments you would have to reply to the email or indeed head to the Web UI to mark them resolved.

One can send a review vote and message over ssh which is quite convenient to a point I locally have aliases +1 / +2 to do it directly from the command line instead of heading to the web browser.

The API is quite powerful (the Gerrit web UI entirely relies on the REST API). James E. Blair wrote a ncurses client for Gerrit there is a quick demo at https://ttygroup.org/gertty/index.html (Pypi page https://pypi.org/project/gertty/ ).



Google Cloud Run also scales to zero by default, but you can configure the minimum number of instances: https://cloud.google.com/run/docs/configuring/min-instances


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

Search: