r00ty

All of this is layman with some basic understanding only.

So, on the one hand in our galaxy alone there are between 100 and 400 billion stars (wikipedia), now a lot of those have no planets, but of course a lot have many more than our system does. So at least the same number in planets. There’s a good chance there’s more than one planet capable to supporting life among that number.

In fact as we improve our ability to observe our galaxy we are able to verify more and more viable planets and even a reasonable number that are similar to our own planet.

This means that there’s definitely going to be a reasonable chance that somewhere, life has evolved to similar or beyond our level already.

But, this for sure doesn’t mean there’s any reason to expect visitors. That’s because even if they can travel at the speed of light, it’s still going to be thousands of years for the majority of them to reach us, provided they even choose to come to us. Because, from where they are they wouldn’t be able to make out our radio signals, nor likely any other signs of life. So we’d be one of many “potentially live bearing” planets.

So, just my opinion. I think the chance of life being out there is reasonably high, the chance of actually being visited (assuming it holds true that we cannot travel faster than light) is probably very very low.

I mean the list is 50% weird and 50% sensible. I think the idea is that there’s someone most people will know that are in “trustworthy” professions/positions. Although, professional photographer. Not really sure they would be in a more trustworthy position than any other job.

Going to say, I think most of us here either used to pay their GP whatever fixed fee they had. But they’ve taken that option away. Apparently the profession complained. I don’t get that. I mean they by definition know you the requisite amount of time. They literally need to sign that is the case and take your money. But, there we go.

I do luckily have a few friends that are solicitors/barristers. So I generally just ask one of them, and it’s only once every 10 years so…

Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
I mean, that’s what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don’t want to do that in Rust. You kind of have to write simpler code for it to fall into place.

Yes, this ties in with what I’m saying though. You need a paradigm shift in your design philosophy, which is hard when you come from a Cx background.

I also think that in OO there shouldn’t be much cross contamination. It happens (and it happens a lot in my personal projects to be fair) but when well designed it shouldn’t need to be. In C# for example it should be the case that rather than a function owning a resource, a class should. So when using an object between classes you take it as a reference from a method in one class and pass it into a method to another class rather than call that class and make it a dependency of that class too. In this way you would have a one way dependency, rather than a two way.

This kind of thinking has moved into creating objects in rust. Also I think yes within a same class the idea of a function (that isn’t static) accepting an object that is part of the class that was returned by another function in the case class feels very wrong from a Cx style point of view. If we knew we were going to do that, we’d just make it a class level variable and use it in both functions.

Like I say, just another way of thinking and I’m not there yet.

The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

The C# original uses the equivalent of read/write locks. But I found it problematic to work the same way in rust and then discovered the communication option was far easier to implement and actually avoids holding up threads. So went with that. Much easier and much faster in execution I think.

I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

In reality I’m never likely to remake the CPU project in rust. Firstly because I’d need to entirely re-engineer it because it’s extensively using hierarchical classes, which just doesn’t work the same way in rust. And I’m not sure traits would allow me to do things in even close to the same way. But if it were to work with a CPU emulator they need to share the memory, and also the CPU needs its own thread.

So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

This was something I was thinking about the other evening. I needed to get the index to remove some other data anyway and wondered if I’d be better off having a master vector and usize lookups for that data store. It’s one extra lookup, but by index it’s the tiniest and the speed isn’t a real issue anyway. It’s replacing perl scripts pulling data from mysql. It couldn’t possibly run slower than that :P

Thanks for the commentary though and I think I’m going to make the changes to use indices to lookup data. I wanted to re-order the way things are done a bit anyway. The problem I see potentially is that the lookups probably need to be regenerated every time I delete something. But actually I think that since it is rebuilt from a file on load. Maybe I just remove the items from the lookups and leave them in the vector. Since next run they would be gone anyway.

Going to second other comments. Even without archinstall. It feels like it will be harder than it is. Umm, just save yourself a bit of time and configure the network and install a console editor (nano/vim whatever) while in the chroot (if going full manual). It was a minor pain to work around that for me.

There are pages discussing how to do everything (helps to have a laptop with browser, or a phone to look them up). At the end, you generally know exactly what you installed (OK no-one watches all the dependencies), and I’ve found any borks that happen easy to fix because I know what I installed.

I remember those times too. The difference today is that there are so many more libraries and projects use those libraries a lot more often.

So using configure and make means that the user also has the responsibility of ensuring all those libraries are up to date. Which again if we’re talking about not using binary install, each also need a regular configure/make process too. It’s not that unusual for large packages to have dependencies on 100+ libraries. At which point building and maintaining the build for all of them yourself becomes untenable really. However I think gentoo exists to automate a lot of this while still building from source.

I understand why binaries with references to other binary packages for prerequisites are used. I also understand where the limits of this are and why the AppImage/Flatpak/snaps exist. I just don’t particularly like the latter as a concept. But accept there’s times you might need them.

The current thing I’m working on (processor for iptv m3u files) isn’t public yet, it’s still in the very early stages. Some of the “learning to fly” rust projects I’ve done so far are here though:

https://git.nerfed.net/r00ty/bingo_rust (it’s a multi-threaded bingo game simulator, that I made because of the stand-up maths video on the subject).
https://git.nerfed.net/r00ty/spectrum_screen (this is a port of part of a general CPU emulation project I did in C#, it emulates the ZX spectrum screen, you can load in the 6912 byte screens and it will show it in a 2x scaled window).

I think both of these are rather using Arc<RwLock<Thing>> because they both operate in a threaded environment. Bingo is wholly multi-threaded and the spectrum screen is meant to be used by a CPU emulator running in another thread. So not quite the same thing. But you can probably see a lot of jamming the wrong shape in the wrong hole in both of those.

The current project isn’t multi-threaded. So it has a lot of the Rc/Rc<RefCell> action instead.

EDIT: Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

Likewise the same channel objects are stored in the structure for the Excel file that is read in (searched for in the m3u file structure).

BTreeMaps used because in different scenarios the contents will be output in either name order or channel order. So just better to put them in, in that order in the first place.

“I think, the people of this country have had of experts” - Michael Gove, (during UK brexit campaign)

The problem with rust, I always find is that when you’re from the previous coding generation like myself. Where I grew up on 8 bit machines with basic and assembly language that you could actually use moving into OO languages… I find that with rust, I’m always trying to shove a round block in a square hole.

When I look at other projects done originally in rust, I think they’re using a different design paradigm.

Not to say, what I make doesn’t work and isn’t still fast and mostly efficient (mostly…). But one example is, because I’m used to working with references and shoving them in different storage. Everything ends up surrounded by Rc<xxx> or Rc<RefCell<xxx>> and accessed with blah.as_ptr().borrow().x etc.

Nothing wrong with that, but the code (to me at least) feels messy in comparison to say C# which is where I do most of my day job work these days. But since I see often that things are done very different in rust projects I see online, I feel like to really get on with the language I need a design paradigm shift somewhere.

I do still persist with rust because I think it’s way more portable than other languages. By that I mean it will make executable files for linux and windows with the same code that really only needs the standard libraries installed on the machine. So when I think of writing a project I want to work on multi platforms, I’m generally looking at rust first these days.

I just realised this is programmerhumor. Sorry, not a very funny comment. Unless you’re a rust developer and laughing at my plight of trying to make rust work for me.

Would have been funnier if you just replied “Groundhog Day (1993)” again.

Yes, but it seems the French language pack is a dependency for pretty much everything else! Who knew?

I’ve been using thinkpads as a work laptop since they were branded IBM Thinkpad. So, I have nothing further to comment.

This does tally up with what I’ve been hearing. Where I’m at there’s been a few hires straight into senior. I’ve not heard of an official junior freeze. At the same time it’s been a long time since I’ve seen a new one.

The problem, as I commented prior, is that if we no longer bring in junior devs to gain this kind of experience, we lose the flow of junior -> senior. But in most places, the people making the decisions won’t consider anything beyond the end of the current fin year.

I don’t think developers are doing it. It’s managers making this kind of decision I’d say.

I’ve been told about companies in the same field as mine with a hiring freeze on juniors. So it’s kinda second hand.

I think it goes further than that. There’s two things happening with regard to AI and software development.

1: Stack overflow has become less common as a resource to solve problems. This, as you say has a problem of input into LLMs for future problems to solve.
2: Junior developers are being hired less because of AI. I assume the idea is that seniors will use AI in the same way they would usually use juniors. Except, they’ve done what business always does. Not think one bit about the future. Today’s senior developers are yesterdays junior developers.

The combination of AI performance drop due to point 1, and the lack of new developers because of point 2 makes for potentially, a bad future for the profession.

We used to have it terrible in the UK in the 90s and 2000s. Basic ADSL was trialled in 1999 and available in maybe late 2000 I think. But it stagnated for a while.

When it came to fibre, interesting things are happening. As well as the “national” (although privatised) telco installing it, there are many independent companies fitting it. Where I live I have the option of the official telco (1000/110) and a private company (1000/1000). Of course I chose the latter :P

Some people have 3 or more options.

Yeah in the future there might well be a handful of overall winners that vacuum up the losers and carve up the territory. But right now, it’s a good time for the normal people… At least for internet.

EDIT: Just to add, some are ISPs and will only sell their own product. Some are wholesale, so even if they’re the only company in your area, you can often buy from multiple ISPs through them.

This one threw me off. I’d muted discord by mistake. Weirdly voice still works. I spent ages checking and double checking settings to see why I wasn’t getting notification sounds and the ptt sound. Dismissing any mute possibility because voice was working.

When I found it was this…

I’m on a pretty old version of mbin (I have some modifications I made for federation issues back when it was kbin). I need to spend a weekend to pilot an upgrade and make sure I can run it safely live.

But even then it’s better in some ways already and I never feel like I’m missing something from lemmy. But I think just calling the whole thing lemmy puts off people that are seeing things through a political lens.

Pretty sure that’s only true about Lemmy. There are other threadiverse apps. The mistake is people calling the threadiverse lemmy.