This blows my mind just as badly and I see it reasonably often: I talk nothing like any AI model that has ever been, it isn't even close. I'm going to be bold and say that even without checking, more analytical approaches like stylometry would prove me right with little doubt. To mistake my writing for being "AI-esque", you would pretty much have to be entirely blind to the stylistic aspects of the text and fall back on even more superficial details like how verbose it is.
Go ahead and throw the comment into your favorite unreliable AI detector. Even though I suspect they're mostly garbage, my writing is just so far away from what AI models do that it doesn't even matter.
edit: I caved into temptation and checked. Big fat zero on GPTZero.
I'm not saying you did and I do think the OP is written with LLM help, but these sentences did make my AI sense tingle: "I just want it to be clear that some of us can pick up Claudisms within just a couple of sentences with no effort. A Claude-generated sentence, in isolation, may not ring any alarm bells. A few of them in a row, however, that's a load-bearing smoking gun right there." The OTT mixed metaphor is part of the problem but I think the sensational tone of the whole post is also part of it
Run say a linux firewall vm with PCI nic passthrough and give the host windows machine a virtio-pci/TAP interface as its network access is one countermeasure off the top of my head I can think of.
I'm imagining a situation where you need to run windows on the host, but you do not want windows itself arbitrating network access -- so you pass through the real NIC to the vm, and route through the vm with a virtio (I think TAP is actually the only option host-side though but still) NIC.
Linux cameras can be made to work well, it's a matter of software. Case in point, newer Ricoh/Pentax cameras actually run an a Linux firmware. (See: GR IV and K-3 Mark II/III). Parts of the software stack are already there, but noones had the will to glue it together correctly for a mobile device usecase, yet.
It's not about will. You need quite some HW for proper calibration, or cut corners a bit. Calibration is otherwise a few step process with some steps having substeps for each light source type.
That's true, but you can cut corners and still end up like 90% there. The software pipelines that can even consume detailed calibration are a pretty recent development anyway. The "cameras on Linux phones are bad" meme is induced purely by the fact that until recently there were like two or three people who have ever sat down to seriously work on this topic across the entire community. Fortunately, it's changing (although the biggest driving factor appears to be the fact that some laptops need a similar treatment now).
Well, rkisp1 driver that drives ISP on RK3399 on Pinephone Pro is available upstream in fully supported manner for like 4 years. It also has full docs in publicly available Rockchip datasheets and partial docs in calibration manuals.
What have people done with it? Some mediocre support in libcamera? :) I don't think lack of handholding is an issue here.
Pinephone is a low volume product. What you need is to get the firmware for some common device that has shipped millions of units so that the number of people with the incentive to make it work is high enough to actually build a community.
There are many such devices already. What is limited is number of people interested in FOSS/independent camera stack development AND usage/users, not lack of devices. Pine64 built and shipped about 60k phones to audience that could be the most interested/receptive - and it made about 5 people interested in doing indepth real work, that I know about.
Also RK3399 is not just pinephone pro, it's way more prominent in other things - notebooks, SBCs, ... whatever. Same ISP is in i.MX SoC, which covers another whole range of devices.
Not sure what 100's of millions shipped units to disinterrested audience achieved?
I don't know what the deal is with Linux and cameras. I've got Fedora installed on this old Retina MBP and apparently Linux somehow stopped supporting the built in webcam. I've never heard of a device losing Linux support but here we are.
Once the code is in the mainline kernel tree, things tend to stay supported indefinitely.
Some devices "work" without having real support by having some binary blob or third party code which is written against a specific kernel version. The code has to be updated when the kernel changes, which is why it's supposed to be in the kernel tree, but because it isn't the kernel developers don't know anything about it and aren't maintaining it. So then instead of working indefinitely it works until whenever third party stops updating it for current versions of the kernel. Which is why all the drivers should be in the kernel tree.
Of course, Apple isn't really that interested in supporting Linux since it's a direct competitor to macOS rather than a way to reduce their dependency on Microsoft/Google, so their hardware is more likely than most to be stuck using some reverse engineered alpha driver or proprietary blob extricated from the macOS one.
Once code is in mainline, it's in mainline. It doesn't mean things will work, lol. It means things will rather regularly break, because many people modify shared code you depend on without ability to test on your particular HW.
Not saying pushing mainline is bad. But assumption there's any kind of "support" is wrong. Code is there. That's all. You have to support it if you want it to work.
(This is very particular to HW/drivers support, Linux core is supported well, I guess.)
First, I would like to preface that this is alpha and should not replace anything in prod at the moment.
What I like about how SIEMatic is built:
* Django (personal familiarity)
* Agent, Indexer, crawlers and web all share a codebase with separate settings
* Search language is built around django orm, built-in jinja2 and ast.literal_eval makes it very versatile, I will be writing some tutorials soon
* search commands designed to handle dataframes, Django Querysets and records (lists of dicts) with predictable conversion between them (you can filter early in you search pipeline)
* from local on sqlite (rundev command) to distributed on postgres with scaling/tuning tips
* comes out of the box ready to monitor your host and provide dashboards and savedsearches
* crawlers handle data retention, alerting, summary event generation and more
There's a bunch more, but again, this is alpha software.
IDK about OPs setup, but I run a pile of E5-2683v4 Xeon recycled servers for Ceph and self hosted business SaaS usage.
One node's ipmitool sensor report (and self-monitoring PSU, so grain of salt, but my UPS side monitoring tracks closely), reports 250-300w average power use. This though, mind you is for running 22 spinning disks, 2 SAS/SATA SSDs, and 4 NVME ssds, and 768GB of DDR4.
Mid-gen 2015ish Xeons were not great at power reduction, but if you are pegging the cores, they were never particularly slow, and they did have lots of PCIe lanes. This boils down to the CPU/mobo itself not being that big a cost floor, especially if you have high utilization rates.
As a comparison, my main desktop development machine, running a Threadripper 9970X, 128GB of DDR5, a RDNA4 GPU, and a small pile of NVME drives has a power floor of roughly 250W. Some CPU centric workloads you'll definitely lose out on on the older gens of machines, but they are by no means impractical.
Maybe for a desktop usecase they are absolutely suboptimal nowadays, but for a lot of realworld usecases I would say they're still relevant.
---
Like the author posts for the LLM usecase, I think optimizing the hardware choice to the application and not leaving levers unpulled is a big key, especially considering how wide a variety of bandwidth/power draw/peak frequency/corecount SKUs exist in the Xeon lines. Without knowing what you intend to run and fitting the correct processor to it, you will end up with a disappointingly poor environment fit.
Take the volume and mass of lobbying by all of data broker companies, data collection companies, and executive agencies.
Combine that with the character of practically every law written involving data privacy, use, IP, and associated regulation of activity around these since the 1990s. It becomes painfully clear that the interests of private citizens have not had a seat at the table, and the Constitution has been taken as an inconvenience to bypass, not a guiding document.
The core sticking point is, I think, is that Section 230 was envisioned as a 'common carrier' exception. Common carriers do not apply editorial control to the content they transmit.
In the modern landscape, where practically every mainstream (and most of the non mainstream even) platform has extensive policies and applies them in a manner that's equivalent to editorial control, they are no longer a common carrier, they are a publisher.
Should that exemption and safe harbor be expanded to all publishers? If no, do you really want the Government picking and choosing favorites? Either way you choose, I believe there will be many first and further order implications.
You can either get Congress to modify the definition, or you could try to get a case through the courts to clarify its interpretation. As one of those indirect implications, I am actually not sure which one would be more of a footgun.
> The core sticking point is, I think, is that Section 230 was envisioned as a 'common carrier' exception. Common carriers do not apply editorial control to the content they transmit.
No, the writers of Section 230 (Ron Wyden and Chris Cox) envisioned the opposite, that websites hosting user-generated content would not be common carriers, would be free to develop new ways to moderate and curate content as they wished, and could not be punished for applying their own viewpoints to their moderation.
From Wyden's and Cox's amicus brief in Gonzalez v. Google confirming that targeted recommendations are protected by Section 230 [1] (related summary at [2]):
> Section 230 does not permit the Court to treat YouTube’s recommendation of a video as a distinct piece of information that YouTube is “responsible” for “creat[ing],” 47 U.S.C. § 230(f)(3).
[...]
> Section 230 protects targeted recommendations to the same extent that it protects other forms of content curation and presentation. Any other interpretation would subvert Section 230’s purpose of encouraging innovation in content moderation and presentation.
From Wyden's and Cox's reply comments to an FCC rulemaking process regarding whether the FCC has authority to interpret Section 230 (it does not) [3]:
> The first is that Section 230 does not require political neutrality. Claiming to “interpret” Section 230 to require political neutrality, or to condition its Good Samaritan protections on political neutrality, would erase the law we wrote and substitute a completely different one, with opposite effect. The second is that any governmental attempt to enforce political neutrality on websites would be hopelessly subjective, complicated, burdensome, and unworkable. The third is that any such legislation or regulation intended to override a website’s moderation decisions would amount to compelling speech, in violation of the First Amendment (regarding which, see section VIII below).
[...]
> The reason that Section 230 does not require political neutrality, and was never intended to do so, is that it would enforce homogeneity: every website would have the same “neutral” point of view. This is the opposite of true diversity.
The above quoted statements denying a requirement of political neutrality apply equally if you replace "political neutrality" with the more general "viewpoint neutrality".
Well tinygo takes some go bindings they implemented for llvm, https://github.com/tinygo-org/go-llvm, uses the Go standard library for parsing, and wires it up to a LLVM IR generator, with a set of flexible backend/machine definition machinery.
You could likely improve gobee to use tinygo's packages directly, instead of transpiling to C and calling into clang, and the licenses of the two projects look compatible. You'll still need to deal with defining a subset to pass the verifier, of course.
---
From the README:
> Replace clang. clang's BPF backend gives us CO-RE, BTF, and verifier-friendly codegen for free. Reimplementing that costs years and gains nothing.
The primary gotcha you may hit if you try this is how much of the BPF features are implemented by clang, and how much is instead implemented in core LLVM. Even with a LLVM sitting next door you could pull out, the harnesses may not exist independent of clang, but I have not looked THAT deep.
The title says 'standard library'. Are you saying that, in the context of C, that it is an error to take that to mean an implementation of libc?
Yes, I know the author's writeup then goes on to say that it is not a libc with a pile of questionable justfication. This is a custom runtime, in a single header no less, which is admittedly impressive, especially considering it provides runtime and thread safety primitives. This does not rise to the level of claiming the idea of a 'standard libarary' though, IMO. In that, I think the author misses the point.
reply