the_sisko @ the_sisko @startrek.website

Posts

2

Comments

109

Joined

2 yr. ago

Sphinx has warnings for these already. They're just suppressed and ignored :)

That was a great episode actually, my only complaint was that he didn't seem to require serious therapy afterwards.

Same with O'Brien's mental imprisonment episode, though at least they tried to show the psychological damage there. He just managed to get over it at the end of the episode 🫠

Yeah, that's probably the best explanation. Or maybe she just knows her deep seated desires, and uses them to imagine how Fenna would be?

Yeah...Star Trek has never been particularly good at one-off romance episodes, and this is certainly one of those.

Yeah, I don't think that I enjoyed any shoehorned romance with Picard especially...

The episode also has Dax asking O'Brien to boost the top speed of Seyetik's ship to warp 9.5 to avoid a potential supernova, a prominent example of Star Trek supernovae being apparently able to travel faster than light. So there's that.

Lol now that you mention it, yes that is quite silly.

I also remember a moment where O'Brien reports that he increased the speed to warp 9.6, and Dax asks "wasn't the theoretical maximum warp 9.5" and he's just like "it was." Top tier O'Brien right there.

Street level is not the same thing as "among car traffic". For instance, there's a stretch of the N-Judah in SF between Embarcadero and 4th & King which is on street level, but in fact it is in an entirely separate right of way, where it is illegal for cars to drive. And unlike other places in SF where it's illegal for cars to be (like bike lanes, bus lanes, Market st), people actually respect that. So it's entirely possible to avoid the private car right of way. If you can avoid intermingling with cars, and you get signal priority, then you'll go faster than cars, because you're not stuck in traffic and you don't need to wait for the lights.

The issue is that in this segment, I haven't noticed much in the way of signal priority. The N, which is far more important than any private car on those intersections, has to wait when it really should just sail through intersections, because the signals knew the N was coming and changed ahead of time.

I know that this can be achieved more or less with BRT, but it seems absolutely silly to put in the rails without having a dedicated right of way, and yet that's what the majority of SF's above-ground light rail is. IMO, if there's light rail on the street, either it should be car free, or the railway should have curbs surrounding it to prevent intrusion from cars. Full stop.

For what it's worth, ENT is set around 2150, SNW around 2259, TNG starts around 2364, and PIC around 2399. In my mind, ENT is pretty far removed from the SNW/TOS era that you'd say is well covered. There's a lot of "untouched" canon to discuss, like the Earth Romulan war. So long as temporal wars are forgotten, I'd be excited to see more ENT stuff.

But I also agree that just going forward into the 25th century would be nice too. Ideally for me I'd prefer to see a clean break from the TNG/PIC nostalgia characters: just the next, next generation, with a new captain and crew.

I do like Jeri Ryan's Seven a lot, and would love a Captain Seven, but there's something to be said for just starting the new thing and building the next big dynasty of trek, rather than borrowing characters.

For your first part, that would make sense, except Nidell isn't supposed to remember anything about Fenna. I don't know how Sisko would expect her to think of Fenna as something she'd want to become, since she knew nothing about her. That was what made the line weird to me.

For your second part - agree on both actually! I haven't seen any particular DS9 specific community in here or elsewhere. Maybe we can be the change we want to see, lol. Maybe a new community or a weekly episode discussion or something.

With the caveat that this only applies to my city, San Francisco... I prefer buses. SF horribly mismanages its "trams"* where they run at ground level through the streets. They must follow all stop signs and traffic rules. They don't even get signal priority. So it's a quite jarring experience to get into a train underground, exit the tunnel to the street, and begin stopping every block and waiting at red lights.

Fact of the matter is that, if you're going to be treated like a car, it's better to be more maneuverable as a bus. Buses can avoid double parked cars, and have a fighting chance of squeezing through a gridlocked intersection. With a bus lane, they can use it but they don't have to, where's trams are trapped in a traffic lane (frequently the centermost lane) while idiots make (frequently illegal) left turns.

Muni light rail - K, J, L, M, N, T, F

The cable cars are quite different from trams, they hook into a cable under the ground to get "dragged" along, they're not moving under their own power. Makes them quite expensive to construct and operate, and you can hear the cable noises a block away even when there's no cable car nearby.

I mean they're also iconic and loads of fun to ride, but I think there's a reason people don't go installing new cable cars.

I see what you mean. The python ML ecosystem is... not far off from what you describe.

But please consider Python as a language outside the pytorch/numpy/whatever else ecosystem. The vast majority of Python doesn't need you to setup a conda environment with a bunch of ML dependencies. It's just some code and a couple of libraries in a virtualenv. And for system stuff, there's almost never any dependency except the standard library.

I mean with that attitude, we should only have shows set in the 32nd century! After all, time has moved forward, right? ;)

In all seriousness, that argument may have made sense when Enterprise came out, but now there's four seasons of characters, setting, and story, which could be expanded on as a sequel. "Prequel" depends on your frame of reference.

They probably know what it is, but it's a bad point if they're trying to paint DAGs as esoteric CS stuff for the average programmer. I needed to use a topological sort for work coding 2 weeks ago, and any time you're using a build system, even as simple as Make, you're using DAGs. Acting like it's a tough concept makes me wonder why I should accept the rest of the argument.

Can't say I have a strong feeling about Gradle though 🤷‍♀️

Can't speak for the whole country but my employment is at-will, meaning it can be terminated by either side at any moment with no notice.

It is considered polite and relatively standard to give two weeks' notice prior to leaving your job, but there's no requirement in any of the jobs I've had.

Of course, employers don't have that same "polite standard" of two weeks, it's not unheard of for people to be fired on the spot. Though it's definitely unusual. For broader layoffs, it's pretty common to get several weeks of notice and pay.

You might be even more concerned to find that your Fedora package manager, DNF, is also written in Python: https://github.com/rpm-software-management/dnf

Fact of the matter is that Python is a language that gets used all the time for system level things, and frequently you just don't know it because there is no ".py" extension.

I'm not sure I understand your concerns about python...

1. Performance is worse than C, yes. But writing performance sensitive code in Python is quite silly, it's common to put that in a C library and use that within python to get the best of both worlds. DNF does this with libdnf.
2. "It feels like an extension of proprietary hardware planned obsolescence and manipulation." This is very confusing to me. There has been one historic version change (2->3) which broke compatibility in a major way, and this version change had a literal decade of help and resources and parallel development. The source code for every Python interpreter version is freely available to build and tweak if you're unhappy with a particular version. Most python scripts are written and used for ages without any changes.
3. "i don’t consider programs written in Python to have permanence or long term value because their toolchains become nearly impossible to track down from scratch." Again, what? As I said, every Python version is available to download, build, and install, and tweak. It's pretty much impossible for python code to every become unusable.

Anyway, people like the Fedora folks working on anaconda choose a language that makes sense for their purpose. Python absolutely makes sense for this purpose compared to C. It allows for fast development and flexibility, and there's not much in an installer program that needs high performance.

That's not to say C isn't a very important language too. But it's important to use the best tool for the job.

Anaconda is just an OS installer program. At least, the Anaconda that you're referring to. After installation, it's gone.

There is also Anaconda which is a Python platform/package system/whatever. Maybe you're confusing the two?

If Seven of Nine is the only character from Voyager who is a main character, then it still strikes me as a TNG spin-off, given that the main cast would also include Jack Crusher (Son of Picard) and Sidney LaForge (Daughter of Geordi), and probably some appearances from Beverly Crusher, Diana Troi, Will Riker, etc... As @StillPaisleyCat@startrek.website mentioned, it could turn into the Jack Crusher show, but even without that, Voyager characters would be second class citizens in comparison. I'd love to see Janeway, Paris, Kim, Torres, Tuvok, heck even Neelix (maybe not Chakotay) but they'd be cameos at best. And with 10 episodes a season, we'd be lucky to get more than one or two of those appearances.

It's not as if I watch everything that way. Just when I want to enjoy some star trek and can't look all the time. Besides, the audio description tracks are meant for the blind to enjoy the show, they're quite well written and produced. They are also great at surfacing details about the settings or characters which the writers/directors wanted to be noticed, but I wouldn't have focused on. So they really open up a new and great perspective. And it's a lot cheaper than buying a new TV every few years so I can see all the newer shades of black lol.

I mean, I don't care what the directors think. They can make things for mass appeal, or they can make things for enthusiasts who invest in top-quality TVs with the latest tech every few years, and who invest a lot of time calibrating their TV and putting up the right curtains to block out the sunlight. If they're making it for enthusiasts, great. But these directors are supposed making things for mass appeal, so they should make TV and movies easily consumable in the ways that average people watch.

I watch for the stories, characters, etc. I honestly don't care that DS9 will never be remastered, it's fine the way it is. But I do care when half the bridge is black because Discovery went to black alert, and I guess that means I can't see anymore :P

.(edit: I actually enjoyed "watching" new trek on my phone with the audio description track on while I was doing dishes. Mostly listening actually.)

I initially thought OP was pretty contrived, but that you were being a bit harsh by calling it AI generated. But then I read the comments. Lol, it's terrible.

It's a cathartic, but not particularly productive vent.

Yes, there are stupid lines of time.sleep(1) written in some tests and codebases. But also, there are test setUp() methods which do expensive work per-test, so that the runtime grew too fast with the number of tests. There are situations where there was a smarter algorithm and the original author said "fuck it" and did the N^2 one. There are container-oriented workflows that take a long time to spin up in order to run the same tests. There are stupid DNS resolution timeouts because you didn't realize that the third-party library you used would try to connect to an API which is not reachable in your test environment... And the list goes on...

I feel like it's the "easy way out" to create some boogeyman, the stupid engineer who writes slow, shitty code. I think it's far more likely that these issues come about because a capable person wrote software under one set of assumptions, and then the assumptions changed, and now the code is slow because the assumptions were violated. There's no bad guy here, just people doing their best.