Readit News logoReadit News
dullgiulio commented on We're migrating many of our servers from Linux to FreeBSD   it-notes.dragas.net/2022/... · Posted by u/NexRebular
nine_k · 4 years ago
Don't make a mistake, systemd is not (just) an init system. It's a replacement of more and more Linux userland. I suppose later on it will replace much of the filesystem, network, and process security management tools, stuff like xattrs, ip / ipfw, and selinux.

I suppose that the end goal of the systemd project is an ability to deploy a production Linux system with just systemd and busybox, and run all software from containers.

Not that it's a bad thing to strive for. But it's not going to be Unix as we know it.

dullgiulio · 4 years ago
> But it's not going to be Unix as we know it.

Right, that's Plan9.

dullgiulio commented on Upcoming Features in Go 1.18   sebastian-holstein.de/pos... · Posted by u/dcu
silisili · 4 years ago
What shortcuts would you recommend?

The pattern itself as written above is rather useless. What you end up with is a call 3 libraries deep that returns nothing but "EOF", and you have no idea what happened. In practice, you should really wrap every error return in a message and/or with a callstack. If the shortcut method can a) accomplish that, and b) avoid everything being nested, like try/except tends to do, I think I'd be more interested in the concept.

dullgiulio · 4 years ago
No shortcuts.

Errors reach end users, and they cannot read stack traces.

Every shortcut makes for bad errors, bad troubleshooting and unhappy users.

Errors document code (you literally write, in English, what you were trying to do but failed, at each level of your program.)

Errors report to the user the clear intent that failed and why.

Errors are a huge differentiator in quality. There is no shortcut to quality.

dullgiulio commented on Upcoming Features in Go 1.18   sebastian-holstein.de/pos... · Posted by u/dcu
PaulKeeble · 4 years ago
We need a shortcut for the

if x,err = f(); err!=nil { return _,err }

pattern that is so common in go code. This is my biggest daily gripe and I work around it with a snippet but so much of integration code is this or a variant of it which captures the stack trace and it constantly distracts from the main flow of algorithm.

dullgiulio · 4 years ago
Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf.

I am tired of seeing

SocketException: hostname.com

as full error message.

dullgiulio commented on Time to retire the CSV?   bitsondisk.com/writing/20... · Posted by u/asicsp
nolok · 4 years ago
Xlsx (office format for almost a decade now) are zip and XML all the way. Not fun to look at, but totally readable by a human.
dullgiulio · 4 years ago
Readable but not comprehensible. CSV is hard to beat in that sense, being somewhat "natural" like a table written on paper.
dullgiulio commented on I hate almost all software (2011)   tinyclouds.org/rant.html... · Posted by u/avinassh
greggman3 · 4 years ago
It goes both ways. I certainly hate un-needed complexity but somethings are just complex. Good examples are font rendering https://gankra.github.io/blah/text-hates-you/ and text input https://lord.io/text-editing-hates-you-too/ You think it's going to be easy. It's not. It just isn't.

Often software is too simple. I just recently got my first "Smart Lights" (my mistake). I'm using Apple Home to control them. I put 3 bulbs in a 3 bulb standing lamp. Home has no way to for me to designate those as a single lamp. To Home they are 3 lamps. The solution is supposed to be use normal bulbs and a smart switch. But that precludes being able to set the colors of the bulbs. In other words, they thought it was simple but it's not.

It gets worse. At first I thought this would be cool, but now I realize if I have a house guest, they won't be able to turn on the lights if I left them off. Arguably, if the power is cut and comes back on, maybe the lights should default to full white? At least then, in an emergency they just work. But again, designing lights that do that would be more complexity, not less.

I can even add another wrinkle. My Siri is set to Japanese. So, my English speaking house guests will not be able to ask for the lights to be turned on if I had a HomePod, which I don't. More complexity because the world is complex

dullgiulio · 4 years ago
No, a normal light switch on the wall is all you need.
dullgiulio commented on No Cookie for You   github.blog/2020-12-17-no... · Posted by u/todsacerdoti
munchbunny · 5 years ago
That existed. https://en.wikipedia.org/wiki/Do_Not_Track

It failed horribly because it was voluntary. But now that it's a GDPR requirement, perhaps that might have a snowball's chance in hell of succeeding.

dullgiulio · 5 years ago
No, it failed because it acts on the wrong side. If you don't want to be tracked you shouldn't send cookies in your request.
dullgiulio commented on Why is the Google Cloud UI so slow?   debugbear.com/blog/slow-g... · Posted by u/mostlystatic
shadowgovt · 5 years ago
There's a meta-answer, which is Google is shipping its org chart.

Google Cloud UI is one giant Angular app with components written by sub-teams across wildly disparate timezones, much less offices. Their ability to consolidate resources is poor. They came late-to-the-game on tooling up an infrastructure team to provide both standardized libraries and rigor on how the architecture is used. The duplication of component logic is a direct consequence of this, as those components are ending up in the codebase as a side-effect of different segments of code, worked on by different teams, probably in different offices, "reusing" the same component---but not really, since they might be skewed on the version they're depending on. It's DLL hell in Javascript client form, basically.

And the product as a whole is chasing feature parity, not speed of UI.

The simplest way to not end up like Google Cloud UI is to not try to build a whole-product cloud solution. The second simplest way, if you're Amazon and you've already gone that road, is to have different sub-parts of your mega-architecture be different "apps" (really, different websites), each of which need pull in only the pieces it cares about, and be willing to take a whole-page refresh when the user transitions from one page to another.

dullgiulio · 5 years ago
This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features.

Google does have a problem with management and the org-chart, but not the way you think.

dullgiulio commented on Fucking, Austria changes name to Fugging   theguardian.com/world/202... · Posted by u/galonk
skrebbel · 5 years ago
The name of the capital of Tajikistan, Dushanbe, means Monday as well iirc.
dullgiulio · 5 years ago
Most probably all these names just indicate market day...
dullgiulio commented on Ruby's Proposed STM   chrisseaton.com/truffleru... · Posted by u/chrisseaton
andrewzah · 5 years ago
From what I can tell, both solve different problems.

There are times when one might want async executors like node's event loop or rust's tokio/async-std, but in other situations one might want os threads or "green threads" with a RwLock or Mutex.

What about a few long running threads that use async internally? ;-)

dullgiulio · 5 years ago
That's the Go runtime.
dullgiulio commented on OAuth 3   oauth.net/3/... · Posted by u/andyroid
alyandon · 5 years ago
Lovely - I can't wait to see how horrible something like that is to implement in a language like Go.
dullgiulio · 5 years ago
You have to implement UnmarshalJSON. Between each attempt to deserialize into a possible struct, be careful to return on errors that are not JSON serialisation errors (for example caused by reading from the underlying Reader, etc.)

It's ugly and verbose but there is no need to use empty interface.

u/dullgiulio

KarmaCake day1464December 16, 2014
About
https://github.com/dullgiulio
View Original