There is essentially zero chemical difference whatsoever in sugar vs corn syrup coke. sucrose disassociates in the presence of an acid into glucose+fructose simple sugars. Just being carbonated will disassociate the sucrose.
Just a cynical observation here, but its funny how the author still hangs onto the notion that it is "the best" despite that it de facto cannot be "the best."
Also, maybe dont rely on a poorly maintained app for making secure connections to your systems? Just me?
It is kinda weird how all the chat type tools all spit out such cheeseball language despite that the raw models almost never generate stuff like that. It honestly just makes me feel like the people making this shit are so caught up in their own hype bubble that it doesn't even register to them as abhorrent.
woah hold on a sec. that's not how these clocks are actually used though.
It's a huge huge huge misconception that you can just plunk down an "atomic clock", discipline an NTP server with it and get perfect wallclock time out of it forever. That is just not how it works. Two hydrogen masers sitting next to each other will drift. Two globally distributed networks of hydrogen masers will drift. They cannot NOT drift. The universe just be that way.
UTC is by definition a consensus; there is no clock in the entire world that one could say is exactly tracking it.
Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard. Their goal is to keep events correlated on their own network, and for that they just need good internal distribution and consensus, and they are at the point where doing that internally makes sense. But this is the same problem on any size network.
Honestly for just NTP, I've never really seen evidence that anything better than a good GPS disciplined TCXO even matters. The reason they offer these oscillators in such devices is because they usually do additional duties like running PtP or distributing a local 10mhz reference where their specific performance characteristics are more useful. Rubidium, for instance, is very stable at short timescales but has awful long term stability.
Yeah I really don't understand why they went this direction as it builds considerable additional complexity directly into the application to solve a problem with an external component
I would have probably approached this by implementing a fix for the misbehaving part of k8s, though since there isnt a default LoadBalancer in k8s, I can't really can't speculate further as to the root cause of the initial problem. But most CNI or cloud providers that implement LB do have a way to take feedback from an external metric. I'd be curious why doing it this way wasn't considered, at least.
I had a look and this project is most definitely not open source. Nobody should be making that claim.
Changing the HN headline to soften the project's own bombastic claim isn't really the point of the argument. It would bhe better to highlight any project that is actually working on open source microscopy of which there are many. Flagged
> My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
Interesting to see someone evoke DjVu.
With the exception of IW44 wavelet compression, basically everything the DjVu file format supports has a PDF equivalent. I built a tool to convert DjVu to PDF that preserves the image layers and file structure with nearly equivalent compression.
My tool did expose some edge cases in the PDF standard which was frustrating. For instance, PDF supports applying a bitonal mask to an image, but it does not specify how to apply it if the two images have different resolution (DPI). It took many years to get Apple to bring their implementation into consistency.
The thing that makes vyos "not Linux" is the configuration shell and monolithic configuration file.
Ultimately vyos/vtysh consumes this single configuration file and uses it to template commands or configuration files for other underlying software. For example if you configure ipsec in the vyos configuration file, it will produce a configuration file from a template for FreeSWAN to implement the options you have set.
I don't personally know offhand how things like bridges are configured in vyos and how vyos maps bridge configuration onto the physical interfaces, but I do know that there is more than one way to do it in Linux, and not all ways of doing it are compatible with switchdev interfaces.
Without vyos having native awareness of switchdev device types or support in its configuration templates for applying features in ways that are tested and compatible with switchdev interfaces there's no way to know if a particular vyos configuration will result in something that works with switchdev or not.
Yes, you can always drop to running manual commands to perform fixups or additional configuration but at that point you're losing most of the sauce that vyos provides and you might as well just go back to vanilla linux where you have full control of everything.
It is my understanding that all the linux-based switch os's (Cumulus, OS10, etc.) work similarly -- custom shell + custom configuration file mapping to templated backend configurations. It would be nice to see vyos gain official templates tests and support for hardware accelerated switchdev
Having experience with both; I am confident this would not work as well as you would want it to if even at all. VyOS has no native awareness of switchdev interfaces or their limitations
IIRC the half-width version of these switches are not advertised as having PTP support. I wouldn't have the first clue if it's straightforward to configure it to work with upstream linux but I do use PTP with Dell SmartFabric OS10 so there is likely some way to achieve it.
As impressive as it is, switchdev is a big departure from "Linux networking" though. This is not a great platform if that is your main objective. The interfaces are not "normal" in that respect and huge subsystems of the Linux network stack do not apply.