@jmc@unix.house
@jmc@unix.house avatar

jmc

@jmc@unix.house

Engineer. UNIX person. Australian-American. Member of illumos core team. Building a new machine at Oxide Computer Company!

This profile is from a federated server and may be incomplete. Browse more on the original instance.

tonyarnold, to random
@tonyarnold@mastodon.social avatar

I feel like my career has absolutely stalled.

Having all of this time to reflect and introspect during my illness and recovery over the past few months has left me wondering what impact I believed I was having on my peers and the people around me over the last decade.

jmc,
@jmc@unix.house avatar

@tonyarnold I can't speak to the most recent decade obviously, but I have fond memories of working with you at the University!

jmc,
@jmc@unix.house avatar

@tonyarnold Why would you say the numbers out looouddd

mjg59, to random
@mjg59@nondeterministic.computer avatar

One of the problems here is that the SSH agent protocol doesn't include the host that's being authenticated to in the request. In theory we could implement an SSH agent that popped up a request asking you to agree to the request before signing - but it has no way of knowing who it's signing on behalf of, because the protocol doesn't include the destination

jmc,
@jmc@unix.house avatar

@mjg59 Presumably you could at least look at getpeerucred(3C) on the socket, though, and report on the process that's asking for a signature? Depending on what SSH does to the visible arguments, you might even be able to print something relatively accurate about what name you used to connect to the remote system? You could also presumably grovel in /proc/PID/fdinfo to find out the IP of the remote system to which an apparent SSH process has connected.

rain, to random
@rain@hachyderm.io avatar

disconcerting that "reading a lot of code and thinking really hard" is still unparalleled as a way to find bugs

jmc,
@jmc@unix.house avatar

@rain I'm not sure it's unparalleled, but it is definitely effective. If reading code and thinking hard goes away though I'm not sure how much I would enjoy what comes after that, to be honest.

danderson, to random
@danderson@hachyderm.io avatar

wow, turns out I don't think I've ever deleted a forked repo on github? It takes a remarkable amount of pressing "yes I'm sure" and reauthing. I guess it's treated the same as the only copy of a repo, so that makes sense.

jmc,
@jmc@unix.house avatar

@danderson I feel like each additional level of confirmation is like a growth ring on a tree which has somehow survived several support call fire years

foone, to random
@foone@digipres.club avatar

arch linux is the best propaganda for using windows that I've ever seen

jmc,
@jmc@unix.house avatar

@foone I stand by: https://m.unix.house/@jmc/112177541828522480

whitequark, to random
@whitequark@mastodon.social avatar

rust people: let's make the kernel more memory-safe with rust!
linux people: we have memory safety at home
memory safety at home: eBPF

jmc,
@jmc@unix.house avatar

@whitequark When they say those things is it the actual plan that they're going to redo all or most of the current AOT native compiled C stuff so that it targets eBPF instead? Or is it just misdirection to avoid the Rust stuff?

18+ danderson, to random
@danderson@hachyderm.io avatar

"I just want an apolitical project where each can contribute according to their ability, to a common purpose to be enjoyed by each according to their need. Why do all these commies keep showing up, it is truly a mystery"

jmc,
@jmc@unix.house avatar

@danderson I realise this is satire but it still hurts

ncommander, to random
@ncommander@restless.systems avatar

Trying to figure out what to write about illumos is difficult, because for me personally, the entire experience has been pretty terrible from start to finish.

That said, I really don't want to shit on a project that appears to be struggling with commercial support, and frankly, I'm not exactly playing to its strengths.

As I'm using it, its basically still just SVR4 UNIX, and I'm ignoring the advancements based in ZFS, Dtrace, etc.

jmc,
@jmc@unix.house avatar

@ncommander With the bash core files, do you happen to have a stack traces? Are you setting your locale to something other than "en_US.UTF-8"? I recall hearing this was happening late last year, for folks using locales that they haven't installed on the machine -- I believe it is, sadly, a bash/libreadline bug. See this thread: https://illumos.topicbox.com/groups/omnios-discuss/T45307281d4837de9-Md4c3ab60dfea76fbad6febb0

When you were having trouble with stuff, were you reaching out on our mailing lists and/or via IRC? We try to help when folks are struggling!

jmc,
@jmc@unix.house avatar

@ncommander Sorry, to be clear, when I asked about your locale I mean on the machine that you use to SSH to OmniOS. By default we allow the locale environment variables to pass through the SSH connection, so that you inherit whatever you're using locally. What does "locale" output on your laptop?

jmc,
@jmc@unix.house avatar

@ncommander Huh! That's definitely not an out of the ordinary locale. A couple of quick follow-ups: this was OmniOS bloody, right? Were the crashes in a zone you had set up, or just directly when you SSH to the global zone?

jmc,
@jmc@unix.house avatar

@ncommander Yes, the locale files not actually being present is what I had surmised was causing the bash issue. But I would definitely expect en_US.UTF-8 to be present in a stock OmniOS installation. To be clear obviously it shouldn't crash either way, I'm just trying to get a sense of how to reproduce this.

jmc,
@jmc@unix.house avatar

@ncommander Yeah if you send me the VM image I'm happy to crack it open and poke around!

jmc,
@jmc@unix.house avatar

@ncommander Thanks, I'll take a look!

Apparently OmniOS carries some post-release patches on bash, so I'll try with and without those: https://github.com/omniosorg/omnios-build/tree/master/build/bash

jmc,
@jmc@unix.house avatar

@ncommander I think what @Toasterson was trying to point out was just how nascent things are over there in our ARM corner, and trying to set expectations about how likely it is that there's going to be much documentation at this early stage.

There is definitely no intent to keep people out of the project; illumos has a code of conduct and we welcome users and contributors of all sorts -- I really appreciate you digging in on the bash stuff last night! Thanks again.

jmc,
@jmc@unix.house avatar

@ncommander @Toasterson So, I can't speak for Till, obviously, just for myself and as a core team member (which Till is not, to be clear). I agree that this has not been a great thread in general, and I'm hoping folks on our side will be a little more welcoming from now on here.

I don't think any of this is about credentials. You've had a lot of public, negative stuff to say before really even beginning a dialogue with any of us, and being unhelpfully defensive is an easy trap to fall into.

jmc,
@jmc@unix.house avatar

@ncommander @Toasterson So, on behalf of the project, I'm sorry that you've had a negative experience thus far. You're definitely welcome, if you'd like to be on the mailing lists or in IRC, as a user or a contributor. I will continue to keep an eye on things.

jmc, to random
@jmc@unix.house avatar

lol, kicking the tyres on Arch Linux on my least important laptop. Ran "pacman -Syu", it appeared to succeed. Rebooted. Stuck in a reboot loop with "Welcome to GRUB!" flashing up very briefly. It's amazing that they've recreated the desktop Linux experience of twenty years prior, just like that!

whitequark, to random
@whitequark@mastodon.social avatar

i think one of the most distasteful takes i've ever read is "eBPF is bad because it has a JIT which lets you seed kernel memory with gadgets"

yes, using the computer for the purpose i am using the computer for may allow a motivated attacker to misuse the computer. the solution for this isn't to log off and go live in a forest

infosec brain is incurable and terminal

jmc,
@jmc@unix.house avatar

@whitequark In their defence, as far as I can tell it's essentially accurate -- and there's a lot of push to use eBPF for literally everything in modern systems. "A new kind of software!". "Nobody needs to make kernel modules to extend things anymore, we do it all with eBPF!".

cliffle, to random
@cliffle@hachyderm.io avatar

Two browser windows open. Four tabs open. One of them is Mastodon, which checks for updates in the background and stuff. Another was Github with notifications and stuff.

Guess which tab was generating hundreds of wakes per second and having the biggest impact on my power consumption?

I bet you wouldn't have guessed "Firefox's built-in PDF reader" because I SURE AS HELL DIDN'T

jmc,
@jmc@unix.house avatar

@cliffle @whitequark I feel like usually I am told to look at https://profiler.firefox.com/

whitequark, (edited ) to random
@whitequark@mastodon.social avatar

printf debugging for FPGAs: yes or no?

(pretend that I have already implemented it and resolved the tradeoffs in some techically feasible way that is the closest to what you might want to use)

please RT!

jmc,
@jmc@unix.house avatar

@whitequark Isn't there already a sort of facility like this in some FPGAs where a bunch of internal signals can be logged in a data recorder buffer, and extracted via JTAG and displayed as a wave/timing diagram thing on a computer?

NanoRaptor, to random
@NanoRaptor@bitbang.social avatar
jmc,
@jmc@unix.house avatar

@NanoRaptor I miss when Oscar used to pop out and sing

jmc, to random
@jmc@unix.house avatar

A small PSA, where the S really stands for my sanity:

It's "illumos". In lower case.

Not "Illumos", and absolutely under no circumstances is it "IllumOS". It's just not. Wikipedia even says so.

This message brought to you by another round of our remote UNIX hamlet being noticed from the bright lights of "Hacker" "News".

b0rk, to random
@b0rk@jvns.ca avatar

mounting git commits as folders with NFS https://jvns.ca/blog/2023/12/04/mounting-git-commits-as-folders-with-nfs/

jmc,
@jmc@unix.house avatar

@b0rk I just found that article! I suspect, looking at this structure, you'd want a file handle of (blob ID) for files, and (parent tree ID, tree ID) for directories, and potentially (commit ID, tree ID) for the top directory in a commit. This would get you close to the structure UNIX file systems tend to have: files don't really live in a particular directory, they could be referenced from lots of directories; NFS clients can continue to access them by handle even if that structure changes.

jmc,
@jmc@unix.house avatar

@b0rk That is, to answer your "I don’t understand how real NFS servers do this, maybe they just have a really big cache?" question: generally I would expect that they don't do caching like this at all, and also aren't actually that aware of the whole path of a file at any point, but rather expose basically some relatively static number that identifies the file system + the inode number (or similar), for both files and directories.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • provamag3
  • kavyap
  • DreamBathrooms
  • everett
  • magazineikmin
  • InstantRegret
  • ngwrru68w68
  • Youngstown
  • Durango
  • slotface
  • rosin
  • GTA5RPClips
  • tester
  • PowerRangers
  • anitta
  • thenastyranch
  • mdbf
  • osvaldo12
  • ethstaker
  • vwfavf
  • cubers
  • normalnudes
  • tacticalgear
  • khanakhh
  • cisconetworking
  • modclub
  • Leos
  • megavids
  • All magazines
    •