gilgad13

The feed is algorithmic, but its not personalized, and the algorithm isn't directly optimizing for engagement.

I believe these are the exact technical advancement the top-level poster was contrasting with cable networks, so the distinction matters here.

Just because you want something to have a viable business model doesn't mean it does. If you want to get paid to develop open source software, I think you have a couple of options:

1. Just don't. Work on open source on the weekends, etc.

2. Do it as part of a "commoditize your complements" strategy.

3. Work at a company that is so large they can fund open source development as part of their advertising strategy.

4. Gather together some expertise in existing open source projects and sell consulting. Crucially, you'll probably need to build on top of some existing open source install base or name recognition. Redhat didn't start the linux project or the gnu userland, Percona didn't write mysql, etc. In some sense you are now one of the leaches that posts such as this one complain about.

The fundamental piece in common here is that the open source bit isn't the main value driver for the business.

I imagine that opinions such as this have influenced this recommendation: https://research.swtch.com/deps . I think there is some spirit in Go of not taking on a ton of small dependencies, but that may be a hold-over from before Go had a built-in package manager.

I think as an organization grows to some combination of available resources and severity of an outage this view becomes more and more common.

I agree, with the addition that closing an unbuffered `<-chan struct{}` is a good way to do broadcast notifications (a. la. the context package).

As evidence that channels should be used rarely, and only in small scopes, consider the number of places chan is used in the standard library.

> There are a lot of organizations who want hyperscale style servers but aren't going to start a division to begin making them themselves.

How does this differ from what large players like Dell are offering under the "hyperconverged" moniker. For example, Dell's Vxrail[0] appears (from marketing speak, anyway) to be a single rack with integrated networking and storage that you can ask to "just start a vm".

[0]: https://www.dell.com/en-us/dt/converged-infrastructure/vxrai...

Contra to most of the comments here, I found a lot to agree with in this article:

> You have no soul as a company at that point, you’re just trying to make money with other people, rather than help people with a problem that you know. You may think you have an idea, but it’s not good enough yet.

I think this is the crux of the difference. If you want to have a successful startup, you have to believe that you deserve to exist and believe you have something unique to offer. You cannot just "show up and listen" and get paid the big bucks.

One aspect of Lua that stands out to me is how every feature is carefully designed both in isolation and in composition with the others. The language has relatively few features, but none of them are hanging off the side, the all lean on each other to make a cohesive whole.

I think Lua is a bit unique in this for two reasons. First, they have in intentional open-source but not open development model. Second, because of the way that Lua is embedded inside other projects, there is more willingness to implement backwards-incompatable changes. I'm sure this is a negative for some who want to build a larger, less fractured community, but it has advantages for language cohesiveness.

> The coordinator communicates with each worker using an improvised JSON-based RPC protocol over a pair of pipes. The protocol is pretty basic because we didn't need anything sophisticated like gRPC, and we didn't want to introduce anything new into the standard library.

Interesting that this does not use `encoding/gob` by these criteria. I think `encoding/gob` is a nice example of what is possible with reflection, and I've certainly learned techniques from reading its implementation, but I haven't seen very many uses in the wild and this certainly would seem like a vote of no-confidence.

While this is true, in the context of alpine climbing where I first heard this statement, the bold alpinists who die young are very much not beginner-intermediates. I've interpreted this differently than just the "Bathtub Curve"[1] applied to dangerous pursuits.

Rather, there is a certain amount of objective risk in alpine environments, and the more time you put yourself in that environment, especially in locations you aren't familiar with, the greater the chance that something will eventually go wrong.

I'm always surprised by the number of famous alpinists who weren't killed on their progressive, headline-capturing attempts but rather on training attempts and lesser objectives.

[1]: https://en.wikipedia.org/wiki/Bathtub_curve

I agree with many of the concerns the author raises, but I'm left with the question:

Given all this, what does layering give us?

It gives some deduplication, but only a crude form. It gives some reproducibility from building off a well-known base and tag, but not full reproducibility. It gives some security benefit from building off a well-known base, but not as large a benefit as standard package managers provide.

I would be excited to see a image distribution system based off of something like casync, maybe with an initial rootfs formed through image-focused distributions like yocto[1]. The embedded device ecosystem has been concerned with reproducibility, image signing, and incremental updates for awhile and I think their approaches are very applicable to container images.

[1]: https://www.yoctoproject.org/

I agree, and from the subordinate's point of view I feel having a regularly planned session lowers the barrier to raise issues early without making things confrontational.

Its the difference between "we talked about many things, including this issue" and "we need to meet to discuss this issue". I find the second starts everyone off on a defensive foot, regardless of peoples' best intentions.

As you said, the solution isn't the hard part. The reason that large companies aren't deploying their own solutions for this issue isn't that their engineers engineers that are incapable of developing their own solutions, but because then they would have to carry that patch forever, and if a problem was found with their particular solution they would be on the hook for it.

And yes, I do think this, "but everyone else is doing the same thing so it isn't really our fault" attitude is a problem.

There's a lot of wiggle room in "better", but there are a decent number of distros for which ~95% of the packages are built in a reproducible way, including Debian, Arch, and Yocto: https://reproducible-builds.org/citests/

The rule that the writer should be responsible for closing a channel is a good one to keep in mind, but it is often the case that you want to launch an indeterminate number of generators and collect the results from all of them. For example, you may want to make one connection to each server in the config, or to process each file in a directory in parallel. Because the arms of a `select{}` are determined at compile time, it cannot be used to select over the variable generator-owned channels, and you have four more difficult options:

* Use `reflect.Value.Select`[1]. Having to reach for reflect feels ugly for such a common case, and the performance of the reflect-select is much lower than the native select.

* Create a single channel owned by the reader, pass it to each writer, and arrange for this channel to be closed when the final writer exits, through a waitgroup. There is an example under "Parallel digestion" in the Go Concurrency Patterns blog post[2]. Note the little details to get right. We must launch a separate goroutine to monitor the waitgroup / channel closure. If we accidentally do it in-line at the wrong level, everything will work fine if the total number of items written to `c` is less than `c`'s capacity, but will hang once a worker becomes blocked on `c`. Additionally, the waitgroup is threaded directly into the writers, which may be more difficult if those are implemented in some other generic package.

* Wrap the above pattern up into a `merge` function, such as the one under "Fan-in, Fan-out" in the Go Concurrency Patterns post[2]. The lack of generics means we will have to copy-paste this function everywhere we want to use it. Additionally, this launches a goroutine for every channel being watched, which strikes people as "expensive" for such a simple operation.

* We can construct a function that takes two channels and launches a goroutine that selects between the two and writes to a merged output channel. By constructing a tree of these we can merge an arbitrary number of channels. This is really just an optimization of the above.

None of these options are particularly intuitive. Too often I've instead seen developers create a single channel owned by the reader and either:

* Assume it is never closed and the reader doesn't terminate until the application does

* Rely on some external mechanism to know when to stop reading. If the reader can stop reading without confirming that the writers have stopped writing, this can lead to the writers becoming blocked on sending into this channel, which may prevent them from performing necessary cleanup actions (signaling `.Done()` on a waitgroup, for instance) that cause hangs in other areas.

* Thread a cancellation ctx through every reader and writer. This ensures that nothing hangs, but can result in messages that are sitting in the the channels being dropped. If other areas of code have an assumption like, "every accepted request will receive a response", this can break that.

In addition, many developers have a gut instinct to add some amount of buffering to their channels, which usually results in these backpressure / channel issues being papered over during low-load unit tests, only to rear their head during higher load integration tests or in production, when the debugging story is much more difficult.

[1]: https://pkg.go.dev/reflect#Select

[2]: https://blog.golang.org/pipelines

This is good, but distributing the mining fees evenly across all lawyers will result in too low a fee for the work involved. What if, instead, the parties of the contract would each pick a small set of lawyers ("representing" lawyers) to receive their fees for enforcing the contract. Rather than relying solely on the mining lawyers for this contract to participate in consensus (as that number is now small and adversarially motivated), we would expand the consensus pool to all lawyers who participated in sufficiently similar contract enforcement in the past, using their votes on previous enforcements as an immutable record.

In this design, determining the threshold for similarity may require the participation of a third-party "oracle" or "judge" component.

Maybe I'm missing something, but my read of golang/protobuf#364[1] was that part of the motivation for the re-organization in protobuf-go v2 was to allow for optimizations like gogoprotobuf to be developed without requiring a complete fork. I totally understand that the authors of gogoprotobuf do not have the time to re-architect their library to use these hooks, but best I can figure this generator does not use these hooks either. Instead it defines additional member functions, and wrappers that look for those specialized functions and fallback to the generic ones if not found.

For example, it looks like pooled decoders could be implemented by setting a custom unmarshaller through the ProtoMethods[2] API.

I wonder why not? Did the authors of the vtprotobuf extension not want to bite off that much work? Is the new API not sufficient to do what they want (thus failing some of the goals expressed in golang/protobuf#364?

[1]: https://github.com/golang/protobuf/issues/364

[2]: https://pkg.go.dev/google.golang.org/protobuf@v1.26.0/reflec...

Fair enough. I agree 8x for IPv4 would be hard to swallow.

In either case, having the interning wrapped up in a reusable library is great.

The uintptr / SetFinalize trick to implement "weak" references is pretty cool, but I'd be curious to hear why

    type IP struct {
        hi, lo uint64
        z    string
    }

with sentinel strings like "\04" and "\0\06" for IPv4 and IPv6-no-zone was rejected. Sure, this 8 bytes larger for the implicit string length, but its still not terribly large, and the string comparisons in the normal IPv4 / IPv6 case are very cheap (just length and pointer equality checks). And it doesn't require opening the unsafe jar. Was the extra 8 bytes enough to disqualify it? Or are the authors worried about the fact that this may allocate on each parse of an IPv6-with-zone?

My understanding was that the double fork dance was actively discouraged for any semi-modern system. The man page you link says as much in the "new-style" section, as well as https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.ht....

Just write your server as a straightforward process and let the service manager handle this stuff for you. You'll just be confusing it if you don't.

I think people do deserve to be surprised. Competence is not the same as selflessness. Many people routinely question whether the FBI is operating for the good of the country, but most people at least believe that they are good at their job.

If the practice of ocean fertilization is illegal, how was he hoping to redeem the carbon credits?

If we're golfing:

https://github.com/quartzjer/js0n/blob/master/js0n.c

Appears to work the same way, though it doesn't bubble back type information.

(Also, the `goto * go[ * cur];` trick was pretty crazy the first time I saw it)

Yes, but it will require a call to Verizon to enable the CAT port on the fiber terminator box in your closet. You also need to set it up properly to keep Pay-Per-View and TV Guide working.

http://www.dd-wrt.com/wiki/index.php/Verizon_FIOS_setup_with...

I prefer this reasoning for why people get emotional about programming languages:

When someone says, "Your programming languages sucks", they're also saying, "The way you go about approaching problems sucks", and essentially, "The way you think is wrong".

I think its reasonable for people to get emotional about a claim like that.

Open Congress: http://www.opencongress.org/ seems like something pretty close to what you are describing. I think its just a layer on top of the thomas.loc.gov system someone else mentioned, but it also does tracking of who changes/supports what.

Judging from the number of comments, it isn't very heavily used.

Perhaps that was the original goal, but now-a-days its pretty rare for a customer to turn off his or her modem, so its unlikely a customer would ever give up an ip address that could be used by someone else.

If pooling was the true original reason for dynamic IPs, it usefulness for that purpose has already passed, regardless of IPv6.

Yes, they just added it.

https://wiki.archlinux.org/index.php/Package_signing

Its been a bit of a headache for me, but that's mostly because I can't just blindly `pacman -Syu` through the update.

In C, at least, it helps to think of regions of memory independently of any meaning overlaid on top. For instance, there is plenty of code that depends on behavior like this:

    struct list_node {
        struct list_node * next;
        struct list_node * prev;
    }
    
    struct useful {
        /* This struct should be part of a list, so include the list header first */
        struct list_node;
    
        /* That data that this struct is storing follows */
        in_addr_t sip;
        in_port_t sport;
        in_addr_t dip;
        in_addr_t dport;
    
    }

Then, you can write a generic list walker by casting the a "struct useful * " to a "struct list_node * " since the first fields will match up.

This is just one example, another would be parsing and unwrapping ip headers and data sections. As I'm sure you've noticed, C prefers explicit to implicit, and this applies to the layout of memory as well.

edit: example: http://stackoverflow.com/questions/3766229/casting-one-struc...

This is a valid questions, because iirc, as long as these companies don't distribute their linux fork outside of their company, they do not need to release the source. GPL takes effect when you distribute binaries, not when you create them.

To do this, wouldn't they have to effectively block SSL and SSH connections as well? SSL is used in OpenVPN and some Cisco implementations. And we all know that you can tunnel any port over ssh.

Or is the plan that the punishment for stepping outside the lines be enough to keep people from experimenting with these technologies?