Shouldn't you already be using low privilege accounts for stuff like gathering information about prod?
Overprivileged accounts is a huge anti-pattern for humans too. People make mistakes. Insider threats happen. Part of ops is making it so users don't have privileges to do damage without appropriate authorization.
I've never read Peter Thiel's books, but isn't that kinda a part of his playbook? Monopolies, but driving progress? "Competition is for losers"? I never fully understood it because it seems like then you're just competing with yourself.
I've been interested to hear more about use cases for these "hybrid" MCUs, can you share a bit about why you chose that over something like a Cortex-A running linux, or an SoC with -A and -M cores?
It's a good question - unfortunately I don't really have a good answer...
Almost all of my embedded activities are for a my own hobby purposes, and I just like the ability to go 'as low as I can' with projects on MCUs. It's nice to be able to use the device's peripherals as much as possible (hardware DSP etc) and I'm not confident in how I'd do that on a Linux based system. I'm in to building my own ham radio Software Defined receivers and it's nice to keep it completely real time.
If I were to be doing this stuff professionally (and I am very close to people who do at work) then yeah I'd probably be using Zephyr or something.
Ah interesting! I work on (very expensive) SDRs and we make pretty heavy use of Xilinx Zynq Ultrascale SoCs. They combine Cortex-A, Cortex-R, and FPGA fabric all in one package, with some fancy interconnects. So you can handle the hard realtime stuff on an RTOS or in the FPGA, then send the data over to the application processor with a hard float ALU to crunch some numbers (or build some kind of dsp IP into the FPGA, idk much about that side of it).
I've also seen some cool stuff with the BeagleBone products, which have a few TI custom architecture DSPs and "realtime units" which you can communicate with via Linux.
But yeah, I can certainly see how just doing it all on a super fast MCU could be easier and cheaper without the backing of commercial enterprises.
I've always thought it would be cool to design a "poor man's zynq" hat for a SBC. Stick a RP3050 and a Lattice FPGA on there and set up some SPI / UART connections.
Setting aside any concept of who's "right" or "wrong", if I got an email like this from the MD of a customer, I'd share it with my team, we'd all laugh a bit, take a deep breath, and find a way to de-escalate the situation.
Similarly if I were buying product from a supplier and they made an immature joke I found hurtful, I would probably just ignore it. If it was a recurring problem maybe I'd say "I really didn't appreciate when you <xyz>'d, can we keep this focused on business in the future?" And if that didn't solve things, I'd see if someone else could be assigned to handle the account.
I hope those examples don't minimize what either side is feeling, but I have to say that I don't feel I've seen anything in this thread that gets my blood pumping. Dealing with difficult or rude people is part of the job and part of life.
Taking things personally, especially in business, is a _very_ expensive luxury. And if that isn't convincing enough, if you still feel angry about it in a month you can usually yell at them later. But if you escalate today and feel foolish about it later, it's a lot more difficult to mend the wounds.
Bose, though, makes a more nuanced distinction in their announcement, which is linked to in the article
> Open-source options for the community | We’re making our technical specifications available so that independent developers can create their own SoundTouch-compatible tools and features.
Bose never claims they're making the speakers open-source, it's lazy reporting by The Verge. They're just making it a little easier for the community to build stuff if they want.
While actually releasing the source code for the speakers would be best, there might be some legitimate business concerns. To me this is a step in the right direction, and their official announcement accurately represented that.
I would imagine there's a "sue the person who has money" factor at play, but I think there are also some legitimate questions about what role LLM companies have to protect vulnerable populations from accessing their services in a way that harms them (or others). There are also important questions about how these companies can prevent malicious persons from accessing information about say, weapons of mass destruction.
I'm not familiar with psychological research, do we know whether engaging with delusions has any effect one way or the other on a delusional person's safety to their self or others? I agree the chat logs in the article are disturbing to read, however I've also witnessed delusional people rambling to their selves, so maybe ChatGPT did nothing to make the situation worse?
Even if it did nothing to make the situation worse, would OpenAI have obligations to report a user whose chats veered into disturbing territory? To whom? And who defines "disturbing" here?
An additional question that I saw in other comments is to what extent these safeguards should be bypassed through hypotheticals. If I ask ChatGPT "I'm writing a mystery novel and want a plan for a perfect murder", what should its reaction be? What rights to privacy should cover that conversation?
It does seem like certain safeguards on LLMs are necessary for the good of the public. I wonder what line should be drawn between privacy and public safety.
I absolutely believe the government should have a role in regulating information asymmetry. It would be fair to have a regulation about attempting to detect use of chatgpt as a psychologist and requiring a disclaimer and warning to be communicated, like we have warnings on tobacco products. It is Wrong for the government to be preventing private commerce because you don't like it. You aren't involved, keep your nose out of it. How will you feel when Republicans write a law requiring AI discourage people from identifying as transgender? (Which is/was in the DSM as "gender dysphoria").
People look at laws like Chat Control and ask, "How could anyone have thought that it was a good idea?" But then you see comments like this, and you can actually see how such viewpoints can blossom in the wild. It's baffling to see in real time.
The underlying problem is that the closure of widely shared intuitive beliefs about data privacy is quite nonintuitive. I routinely find myself in conversations, both online and offline, where people are baffled to discover that data privacy rules get in the way of some nice thing they're trying to do.
> the “warmup” time for a unikernel is subsecond whereas the warmup time for, say, containers is… let’s just call it longer than the warmup time for the water i am heating to make some pourover coffee after i finish my silly post. to dismiss this as a profound advantage is to definitely sell the idea more than a little short.
I'm surprised to read that unikernels would start up much faster than containers. It seems like a unikernel needs to do more work (load kernel, and load app), in a more restricted way (hypervisor) than simply loading the app in a cgroup + namespace and letting it rip.
Are you sure this is an apples to apples comparison of similarly optimized images?
I think there's merit to your criticisms of the way docker is used, but it also seems like it provides substantial benefits for application developers. They don't need to beg OS maintainers to update the package, and they don't need to maintain builds for different (OS, version) targets any more.
They can just say "here's the source code, here's a container where it works, the rest is the OS maintainer's job, and if Debian users running 10 year old software bug me I'm just gonna tell them to use the container"
Yeah I'm not against Docker in its entirety. I think it is good for development purposes to emulate multiple different environments and test things inside them, just not as a way to ship stuff.
> other architectural concepts such as the complete lack of an interactive userland is far more beneficial when you consider what an attacker actually wants to do after landing on your box
What does that have to do with unikernel vs more traditional VMs? You can build a rootfs that doesn't have any interactive userland. Lots of container images do that already.
I am not a security researcher, but I wouldn't think it would be too hard to load your own shell into memory once you get access to it. At least, compared to pulling off an exploit in the first place.
I would think that merging kernel and user address spaces in a unikernel would, if anything, make it more vulnerable than a design using similar kernel options that did not attempt to merge everything into the kernel. Since now every application exploit is a kernel exploit.
A shell by design is explicitly made to run other programs. You type in 'ls', 'cd', 'cat', etc. but those are all different programs. A "webshell" can work to a degree as you could potentially upload files, cat files, write to files, etc. but you aren't running other programs under these conditions - that'd be code you're executing - scripting languages make this vastly easier than compiled ones. It's a lot more than just slapping a heavy-handed seccomp profile on your app.
Also merging the address space is not a necessity. In fact - 64-bit (which is essentially all modern cloud software) mandates virtual memory to begin with and many unikernel projects support elf loading.
Overprivileged accounts is a huge anti-pattern for humans too. People make mistakes. Insider threats happen. Part of ops is making it so users don't have privileges to do damage without appropriate authorization.
reply