meet.hn/city/40.7596198,-111.886797/Salt-Lake-City
Socials:
- bsky.app/profile/joferkington
- github.com/joferkington
---
- joferThat exactly. It's not that it's impossible. It's that it's heavy to efficiently transport heat to the radiators or requires a lot of tiny sats, which have their with problems.
- What really worries me is that I keep hearing "cooling is cheap and easy in space!" in a lot of these conversations, and it couldn't be farther from the truth. Cooling is _really_ hard and can't use efficient (i.e. advection-based air or water cooling) approaches and are limited to dramatically less efficient radiative cooling. It doesn't matter that space is cold because cooling is damned hard in a vacuum.
The article makes this point, but it's relatively far in and I felt it was worth making again.
With that said, my employer now appears to be in this business, so I guess if there's money there, we can build the satellites. (Note: opinions my own) I just don't see how it makes sense from a practical technical perspective.
Space is a much harder place to run datacenters.
- Ah, fair enough! I think I misread some things around the library initially awhile back and have been making incorrect assumptions about it for awhile!
- Good point, but I think we're talking past each other a bit.
Typing in python within the scientific world isn't ever used to check types. It's _strictly_ only documentation.
Yes, MyPy and whatnot exist, but not meaningfully. You literally can't use them for anything in this domain (they wont' run any of the code in question).
Types (in this subset of python) are 100% about documentation, 0% about enforcement.
We're setting up a _documentation_ system that can't express the core things it needs to. That worries me. Setting up type _checks_ is a completely different thing and not at all the goal.
- Yes, python is not statically typed. It shouldn't be. Don't expect static typing behavior and typing in python is _not_ static typing in any way. It's documentation only, not static typing.
- I'm aware of that. As explained in the original comment, not being able to denote dimensionality in those is a major limitation.
- That one's new to me. Thanks! (With that said, I worry that 3rd party libs are a bad place for types for numpy.)
- It actually doesn't, as far as I know :) It does get close, though. I should give it a deeper look than I have previously, though.
"array-like" has real meaning in the python world and lots of things operate in that world. A very common need in libraries is indicating that things expect something that's either a numpy array or a subclass of one or something that's _convertible_ into a numpy array. That last part is key. E.g. nested lists. Or something with the __array__ interface.
In addition to dimensionality that part doesn't translate well.
And regardless, if the type representation is not standardized across multiple libraries (i.e. in core numpy), there's little value to it.
- Unless I'm missing something entirely, what would that add? You still can't express the core information you need in the type system.
- One of my biggest gripes around typing in python actually revolves around things like numpy arrays and other scientific data structures. Typing in python is great if you're only using builtins or things that the typing system was designed for. But it wasn't designed with scientific data structures particularly in mind. Being able to denote dtype (e.g. uint8 array vs int array) is certainly helpful, but only one aspect.
There's not a good way to say "Expects a 3D array-like" (i.e. something convertible into an array with at least 3 dimensions). Similarly, things like "At least 2 dimensional" or similar just aren't expressible in the type system and potentially could be. You wind up relying on docstrings. Personally, I think typing in docstrings is great. At least for me, IDE (vim) hinting/autocompletion/etc all work already with standard docstrings and strictly typed interpreters are a completely moot point for most scientific computing. What happens in practice is that you have the real info in the docstring and a type "stub" for typing. However, at the point that all of the relevant information about the expected type is going to have to be the docstring, is the additional typing really adding anything?
In short, I'd love to see the ability to indicate expected dimensionality or dimensionality of operation in typing of numpy arrays.
But with that said, I worry that typing for these use cases adds relatively little functionality at the significant expense of readability.
- I'm trying to count the rounds of major layoffs in my career (e.g. 10% or more of the company let go at once). I _think_ it's 5, but it might be a bit more. I've been lucky each time, but that also means I wasn't one of the ones taking risks. Layoffs cut from both sides of the performance curve and leave the middle, in my experience.
I wish I'd done this more.
In some cases there was no way to. For example, we once woke up to find that the European half of our team had been laid off as part of huge cuts that weren't announced and even our manager had no idea were coming. There's no good way to do layoffs, but I think that "sudden shock" approach is worst of all, personally. You don't get to say goodbye in any way and people don't get to plan for contingencies at all. (The other extreme of knowing it's coming for a year and applying for your own job and then having 2 months to sit around after you didn't get it also sucks, and I've done that as well. You can at least make plans in that case, though.)
On the other hand, in a _lot_ of other cases, you do have a chance to say goodbye. Take it. This is really excellent advice. It's worth saying something, at very least to the people you really did enjoy working with.
There's a decent chance you work with some of those folks in the future, and even if you don't, it really does mean something to be a kind human.
- Flock really does have a huge amount of potential for abuse. It's a fair point that private companies (e.g. Google, etc) have way more surveillance on us than the government does, but the US and local governments having this level of surveillance should also worry folks. There's massive potential for abuse. And frankly, I don't trust most local police departments to not have someone that would use this to stalk their ex or use it in other abusive ways. I weirdly actually trust Google's interests in surveillance (i.e. marketing) more than I trust the government's legitimate need to monitor in some cases to track crimes. Things get scary quick when mass surveillance is combined with (often selective) prosecution.
- This depends a lot on what you do. Try working with a decision analyst sometime. The entire economic model with a decision tree and monte carlo analysis of cost overruns, etc for a multi-trillion dollar decision will literally be a arcanely-complex spreadsheet or two on someone's laptop.
With that said, it's still a great tool for the job because the different stakeholders can inspect it.
- It requires more input energy, but it's been really good to see electrolysis of H2O for hydrogen generation take off. There are honestly industrial/grid scale operations actually starting now (as opposed to being constructed). E.g. Aces Delta in Utah. 220MW of wind/solar as input (i.e. equivalent to power for a medium sized city) As a disclaimer, my wife works on that project, but I think it's incredibly cool regardless.
Pyrolysis is a less energy intensive way to produce hydrogen, and does deserve more attention. But it still requires methane as a feedstock.
Hydrolysis let's use use hydrogen as essentially a fixed loss battery. It's perfectly complimentary to seasonally variable renewables like wind and solar. Batteries have too high of a loss though time for seasonal or multi-year storage. If you can store it (big if... Not everywhere has a salt dome like Delta, UT), hydrogen really is a great solution.
- Usually airplanes because the instruments are heavy. But yeah, that's the most common case. Hyperspectral sats are much rarer than aerial hyperspectral.
- A major limitation is that most different rock types look essentially identical in visual+NIR spectral ranges. Things separate once you get out to SWIR bands. Sentinel2 does have some SWIR bands and it may work reasonably well with embeddings. But a lot of the signal the embeddings are going to be focused on encoding may not be the right features to distinguish rock types. Methods more focused specifically on the SWIR range are more likely to work reliably. E.g. simple band ratios of SWIR bands may give a cleaner signal than general purpose embeddings in this case.
Hyperspectral in the SWIR range is what you really want for this, but that's a whole different ball game.
- ^ This. Exactly. Low value comment on my part, but as the OP in this case, I feel the need to say that this is the exact issue.
The "smell test" takes longer than you think and often involves an actual interview.
- I have no idea, but yes, I suspect remote positions are heavily targeted and folks are looking for lazy hiring processes.
But when the job description contains a lot of very general terms (e.g. "scientific computing") and every part of your job history is just parroting a specific term used in the job description with no details it doesn't pass the smell test.
I absolutely respect keyword-heavy job/project descriptions. You kind of have to do it to make it through filtering by most recruiters. But real descriptions are coherent and don't just parrot back terms in ways that makes it clear you don't understand what the are. You find a way to make a coherent keyword soup that still actually describes what you did. That's great! But it's really obvious folks are misrepresenting things when a resume uses all the terms in the job description in ways that don't make sense.
I kinda think we've reach this weird warfare stage of folks submitting uniquely LLM-generated resumes for each position to combat the aggressive LLM-based filtering that recruiting is starting to use. I assume people think they can do well in an interview if they can just get past the automated filtering. I'm sure some are trying to do 3 and 4 remote jobs at once with little real responsibilities, too, but I find it hard to believe that's the majority. I may be very wrong there, though...
- As someone who's recently been hiring (sorry folks, position was filled just a few days ago), it's wild to me how distorted things have become.
We had 1200 applications for an extremely niche role. A huge amount were clearly faked resumes that far too closely matched the job description to be realistic. Another huge portion were just unqualified.
The irony is that there actually _are_ a ton of exceptionally qualified candidates right now due to the various layoffs at government labs. We actually _do_ want folks with an academic research background. I am quite certain that the applicant pool contained a lot of those folks and others that we really wanted to interview.
However, in practice, we couldn't find folks we didn't already know because various keyword-focused searches and AI filtering tend to filter out the most qualified candidates. We got a ton of spam applications, so we couldn't manually filter. The filtering HR does doesn't help. All of the various attempts to meaningfully review the full candidate pool in the time we had just failed. (Edit: "Just failed" is a bit unfair. There was a lot of effort put in and some good folks found that way, but certainly not every resume was actually reviewed.)
What finally happened is that we mostly interviewed the candidates we knew about through other channels. E.g. folks who had applied before and e-mailed one of us they were applying again. Former co-workers from other companies. Folks we knew through professional networks. That was a great pool of applicants, but I am certain we missed a ton of exceptional folks whose applications no actual person even saw.
The process is so broken right now that we're 100% back to nepotism. If you don't already know someone working at the company, your resume will probably never be seen.
I really feel hiring is in a much worse state than it was about 5 years ago. I don't know how to fix it. We're just back to what it was 20+ years ago. It's 100% who you know.