914
points
theamk
Joined 9,023 karma
- theamkTL/DR: MacBook Air 13-Inch M1 2020
- Does anyone actually care about linkedin "content"? It seems full of useless articles that only benefit marketers. If all the articles would disappear one day, I doubt many readers would be sad.
(The two-way contact list, on the other hand, is significantly more useful. But you cannot syndicate it, it's tied to the platform)
- "leaking" is the wrong word here - it implies some sort of inefficiency, process which is not working as well as it needs to. Leaky bucket, leaky faucet...
That's not the case here, that center is __dumping__ heat into environment - it is by design, all that electricity is being converted into the heat. By design, it's enormous electric heater.
- This makes no sense.. Python _was_ heavily scrutinized when it was introduced - the whole "Perl vs Python" comparison was pretty popular for a while, with either of those being declared winner, depending on the author.
If there is really a killer argument for Perl over Python that was overlooked in all those years, why don't you say that argument, or even better, write a blog post explaining why Perl is better than Python? Then we could discuss that instead of nebulous "different ways"/
- Python wins hands-down in having readable code.
Perl has so many ways to write the same code, no two codebases are the same - it's practically different languages. Back when I was programming Perl, I remember reading my own Perl scripts I wrote few years ago, and being annoyed with how they were doing everything all wrong... because in those few years, my Perl style has changed significantly. And others' scripts were even worse!
Plus, python had all those neat quality-of-life things useful for day-to-day scripting. For example actual function parameters, exceptions (no more "or die" after each open), pretty big stdlib (I _don't_ miss having to configure "cpan" on each new machine), repr() in language core, etc..
And yes, Python got lucky somewhat - there was a need for "Perl but easier to read and friendlier to new users", and Python has filled that need. And now that need is no longer open, so it's harder for newcomers to fill that niche. But that's life in general - Rust filled the niche of "No overheads like C++ but memory safe", Go has filled the niche of "Compiled systems language with GC" etc... And once a language gets popular, network effects kick in.
- The process is pretty informal, so there are no hard requirements. that said:
- Failures per day: let's say 0-100
- How long to retain records: no hard requirements? I guess a few months at least, some failures are pretty rare
- What's the lifecycle of a failure? Scripts record it, team members investigate it and assign to "root cause".
- Custom scripts:
(1) create ticket per failure
(2) create failure reports (to prioritize work - for example if there were 50 failure reports with root cause of 'github was down' , the priority of "set up github mirror" will get bumped up)
(3) mass-update tickets (for example if github.com is down, there will be few dozens of failed processes because of that)
(4) handle rules for automatic classification (again, if github.com is down, it'd be lovely if I can have a rule: "for the next 48 hours, every ticket which mentions github.com and 503 is auto-assigned to 'github was down' root cause")
- SSO, audit, compliance: nice but not required
- JIRA problems: search sucks. "Find similar ticket" sucks. Rules are missing (or need admin). Even something as simple as "close those 20 tickets and link them all to ABC-1234" is impossible.
- Google sheets: not enough automation. At least I can do "filter rows, copy-paste the 'root cause' field into all of them", and it is pretty fast, but: multi-line outputs don't look good and there are no automation (we did not explore App Script, maybe we should have...)
And yeah, I am getting the feeling this would be a custom job. We have resources in house to do so, but I was hoping there was an existing product. Surely there are people out there who run batch-like jobs and want them to be reliable? Something like data conversion jobs, CI builds, training jobs, etc...
Perhaps it's a good thing for generative AI, I've heard it's pretty good at making websites (and security/availability is not an issue, as this will be internal website not exposed to internet). Or I may revisit Google's App Script...
- Nothing, and that's the route we'll likely end up taking.
It is just that we have money in the budget for those kinds of things, and there is existing product, we'd rather support their creators instead.
- Such a nice design on server-side.. and yet on the client side, it uses system address book - something that Google backs up on the server, and many carriers back up too, and many apps (like Whatsapp) save it too.
"Hey, _we_ don't store your contacts, we are good! Instead you have to manage them yourself, and in process share your presumably "secure" Signal contact list with Apple, Google, Facebook phone carriers and everyone else. But it's not on our servers, so we don't care"
- this all started with git history rewrite in public project...
> Out of curiosity, where's the statement which explains the git history rewriting? This is the first I'm hearing of the whole thing, but rewriting git history is really suspicious tbh
> We never explained the history rewriting and we aren't obligated to. Git is a distributed VCS other people probably still have the history. We made a statement that it wasn't a supply chain attack (With other members of the greater rust community corroborating) in the now deleted reddit thread.
- I think the thing about StepSticks is they all have same (or very similar) pinout - so as long as board is designed for generic "stepstick", you can plug your favorite kind.
Earlier journal log entries mentioned TMC2209_SILENTSTEPSTICK, but most recent schematics removed this designation. Seems like an oversight.
- 1 point
- Some BSDs have concept of "securelevel" - a global setting that could be used to permanently put the system up into the mode which restricts certain operations, like writing to raw disks or truncating logs.
The idea is if you want to modify the the system, you reboot into single-user mode and do what you need. It does not start up ssh / networking by default, so it is accessible to local console only.
And of course plenty of smaller MCUs (used in IoT devices) can be locked down to prevent any sort of writing to program memory - you need an external programming adapter to update the code. This is the ultimate security in some sense - no matter what kinds of bugs you have, a power cycle will always restore system into pristine state (*unless there is a bug in settings parser).
- That's no excuse for disbelieving GPS for extended periods of time.
Google Maps gets it right: it tried to keep you on road, but only for a few tens of seconds. After that, if you are in the middle of uncharted territory, it'll show the marker there.
(This is probably because Google Maps can be used for walking/biking too)
- > the build farm for the next OS update is a god object
This is a very interesting question! It may sound meaningless to you, but modifying firmware images is pretty common when trying to modify locked-down hardware. As in, "I'll unpack the firmware image, set root password and enable telnet, then flash it back". So no, the build farm is not a god object. Whatever controls firmware updates is. Can any app initiate it? Or does it need user's password? Or maybe physical presence? Or a private key that only select people have?
> If sudo couldn't be used from other programs / she'll scripts and doesn't give access to a god account.. But why require people to manually wrap programs..
So, you mean like what "polkit"? This is what systemd is doing - instead of requiring "sudo", commands like "systemctl start SOMETHING" will handle privilege escalation themselves. For example on my computer, running this in terminal pops-up interactive dialog asking for my password. In theory, you can have the whole suite of programs - "secure-cp", "secure-mv", "secure-edit" (see also: "sudoedit"), "secure-find", etc... But it seems pretty wasteful, no? Sure, most common actions (installing/removing apps, configuring networks) can get its own nice privilege-escalating wrappers, but there are many advanced tasks that user can do, and it's much easier to make (and audit) a single "sudo" than hundreds of random scripts.
(Unless you want to have a fully locked-down system where the only OS creator can decide which privileged actions are allowed. Those things exists and are pretty popular: Android and iOS. They are also only usable for a very specific purposes, basically as a remote terminals to server machines running unrestricted OSes without such limitations)
- Please don't use "sh" python library!
By default (1) captures stdout and stderr of all processes and (2) create tty for processs stdout.
Those are really bad defaults. The tty on stdout means many programs run in "interactive" rather then "batch" mode: programs which use pager get output truncated, auto-colors may get enabled and emit ESC controls into output streams (or not, depending on user's distro... fun!). And captured stderr means warnings and progress messages just disappear.
For example, this hangs forever without any output, at least if executed from interactive terminal:
Compare to "subprocess" which does the right thing and returns manpage as a string:from sh import man print(man("tty"))
Can you fix "sh"? sure, you need to bake in option to disable tty. But you've got to do it in _every_ script, or you'll see failure sooner or later. So it's much easier, not to mention safer, to simply use "subprocess". And as a bonus, one less dependency!import subprocess subprocess.check_output(["man", "tty"], text=True)(Fun fact: back when "sh" first appeared, everyone was using "git log" as an example of why tty was bad (it was silently truncating data). They fixed it.. by disabling tty only for "git" command. So my example uses "man" :) )
- TL/DL: yes, it does, and by significant amount
Key fob has nRF52840l, 64 MHz ARM, 1024 KB Flash, 256 KB RAM
Apollo Guidance Computer was 2MHz, ~72 KB ROM, ~4 KB RAM
The comparison might be up to 10x different due to more efficient architecture and different MIPS/MHz ratio, but it does not change much, since the differences are so dramatic.
(This is based on links in the podcast description, which I assume what they talked about. Those pretty new keyfobs, older ones might have something like nRF24LE01, which is only 16 MHz, 18 KB Flash, 1KB RAM)
- If an app requires a permission, how does OS know that it's OK to grant it? For example, I want to backup my system, so I install app which needs a permission called "bypass any file access control and let me read every file". How does OS know it's legitimate and not malware trying to steal data?
It could be "this requires special digital signature from OS manufacturer" -> then the private key of this digital signature is a "god object"
It could be "this requires confirmation from the physically present user" -> then you basically have passwordless sudo
It could be "this requires users pin/password/biometrics" -> then you have regular sudo
Either way, there is some source of authority in here, even if it's called "root key" or "user pin" instead of "root account".
- Raymond's posts are always fun to read, but it sometimes he focuses more on the "proper" methods, and does not even acknowledge that there are hacky workarounds.
Like for this case - sure, you cannot redefine the standard output handle, but that's not what the customer asked for, is it? They said "read" and I can see a whole bunch of ways to do so - ReadConsoleOutput + heuristic for scrolling, code inject into console host, attach debugger, set up detour on logging function, custom kernel module...
To be fair, as a MS support person, it's the exactly right thing to do. You don't want the person to start writing custom kernel module when they should redirect stdout on process start instead. But as a random internet reader, I'd love to read all about hacky ways to achieve the same!
- 8051 is cool, but no one is going to be writing their own homebrew assembler for them, there are plenty of FOSS ones.
And even assembly itself is going away, sdcc is a perfectly good compiler which is sufficient for a lot of 8051 applications.