I didn't want to specifically mention python, haha. But some times I wonder if the end station is that everything will be written in python.

Fedora btw was one of my shortest expriences with any distro, those people were so angry, rude and terrible that Fedora never became more than a short test for me. Imagine 10 angry people shouting in your face, spit, wind and all, that you have to do it their way or f off, and don't question anything.

Slackware is great, and I know, I started using it over 20 years ago, before starting over a decade of distro hopping that ended with me using Mageia for many years. And to be frank, Mageia is a very good distro. It doesn't really have the "distro way", but keeps the GNU/Linux way, while being a breeze to use and having many great tools etc. But it's nothing compared to Slackware, and I've really enjoyed getting back to "do it yourself" and really getting deep into things. Not that you HAVE to do it yourself, because it's a great distro, but even so you can really do it yourself, and it encourages you to do so, and it draws you to do so, and it's alot of fun and a great learning experience always. Let's call it optimization and customization.

And well, people who use Slackware are slackers, and I guess I'm just one of those kind of people
It's a great place to be.

1 members found this post helpful.

I had this as my signature some time ago:
A slacker by nature, a Slacker by choice.
(:

That's to me the signature of insecurity, I have consistently found high level skilled technical craftspeople to be secure and pleasant to deal with. Sure, Linus or Theo are going to bite your head off if you do something dumb or thoughtless or have failed to understand the code you are working on, etc, that might by odd coincidence scare away the very people you don't want in your project anyway, but that's different. I react the same, if you file a dumb issue where you clearly have no idea what you are doing, didn't read the manuals or docs, or even the readme, you won't get a warm fuzzy feeling from my response, but if anyone does the work, and shows they gave it a good try, I'll bend over to help them get their issue resolved.

I know exactly what you are talking about there, so while being diplomatic, I can think of at least 2 other well known distros whose users have this issue, I don't know about their core team members, because I don't interact with them, but your description fits them to a t. What's funny is that such people think they are really good and clever, but actually are just broadcasting the fact that they aren't by such attitudes. Luckily there are many other distros to choose from, so it doesn't matter, it's not a job, and we don't have to talk to everyone.

As an aside, while remaining diplomatic, my experience with fedora is quite different, and I don't in general interact with its users for quite different reasons, I just find that there comes a point where the minutes spent vs benefit gained ratio just gets too skewed, and it's just not worth my time or energy. Doesn't make a distro bad or good, it just makes it not worth my time.

Python can't take over everything because at some point you must get serious, I view python as a fast way to prototype stuff, and that's how a lot of places use it, I think for a long time google prototyped in python, then went to C for the real stuff that actually ran on their production systems. That's why they hired Guido for a while. That's also I think why they created Go, due to some issues they encountered trying to scale C coding to a large pool of constantly varying talent and skill and experience programmers, plus it's probably more designed around web services etc I'd assume. But you'll notice they didn't work on a more efficient version of python instead, the way facebook has done with php.

Tesla uses python, but their datacenter machine learning stuff is done in C, because execution speed and power matters, they are dealing with massive amounts of video data. The cars for sure don't run python because that would be stupid, they need to save electricity and not waste it running slow inefficient languages, so i assume the cars stuff is also done in C, though not sure, I know their datacenter stuff is. C is to me the direct cousin of Perl, Perl being the scripting version of C basically.

Very early on, inxi used a small external module for debugging, in python, written by another guy, that module broke on a MINOR python update, and since he wasn't around to fix it, and it was slow as molasses anyway, I did some research, and embedded that module's logic in Perl into bash inxi, where I was shocked to see it run about 10x faster than the python ever had. I don't remember anymore, it was at least 10x faster, maybe more. Python has been true to another core mission, which they didn't include in the wiki article, which is to not care about existing global codebases, and to feel free to destroy them all ever major release, which is an improvement over their previous strategy of destroying things at random on a minor release. I don't use languages that show this failure to develop, plan, and engineer over years, and thus have to fundamentally break themselves to change stuff. Perl shines in this regard, best in class imo.

That break and subsequent recoding to perl, was when I realized inxi was going to Perl, and Python was never considered for even a millisecond, except as a really funny joke, to see how much slower inxi feature complete would be in python vs perl.

I think Python is popular because it met its design goals, just as javascript has:

https://en.wikipedia.org/wiki/Guido_van_Rossum
it achieves those goals by removing itself to a great distance from bare metal, and that is why it is slow, and cludgy if you are looking for C like baremetal performance and features.

Look at regex in python vs perl, perl is native, best in class, blazingly fast, stunningly so, python it's not native, and to use it is very similar to the cludges you need to do to use regex in PHP. I know you can use these cludges, but they suck, I use regex so heavily in inxi that the idea of having no native builtin regex is... unthinkable to be honest. I do not see how anyone dealing with serious practical extraction and reporting of data could use python.

But popularity pays, I mean, python is, again, very popular in machine learning circles, has solid libraries that are very active, and given machine learning is the definition of prototyped unstable development until it hits very large levels, like tesla, python has found a real niche there.

Perl threading is also a total cludge, similar to the type of cludge that regex is in python, I think that was something raku/perl 6 was supposed to resolve, but I will never pretend threading is fun or easy in perl 5, though I have one program that relies on it, and it's great, but very hard to control or debug, but great, but not native, not intuitive.

I have a friend who is not a programmer, and getting into certain areas of tech very late in life, and he could pick up python to a functional level, which means, objectively, having no programming training, it will be very bad code that works fine but should never see production. Similar to what scientists do, etc.

Perl is much harder to learn, I'm still just hovering around lower intermediate level imo, and each jump I make requires that I learn more fundamental stuff about how a cpu and kernel and operating system really work, aka, bare metal, the more you learn that, the better your perl gets. But Perl was very hard to get towards the intermediate stage, I read some of the main books, but they stop being useful once you get into realworld non trivial situations, it's only now that I will go back to check something in Programming Perl and finally really understand why it's relevant.

Perl was made for a bygone generation of tech people, where basically everyone in tech was kind of best in class, it was a small tight world, and it didn't have much room for beginners.

But Larry Walls unfixable, permanently lethal error, was and always will be, starting Perl 6, which was NOT going to be compatible with Perl 5, then taking almost 20 years to decide that Perl 6 was not going to be released, instead Raku was, in 2019, 19 years after Perl 6 initial design process started. That is one of the biggest screwups I've ever seen. I know I would have switched in 2006 to Perl 5 if it had been clear there was a forward path, but it was literally not certain until a few years ago that Perl 5 would continue. Perl 6/raku syntax is ugly and weird, sorry Larry, looked at it, and zero interest.

It was only in 2018 that I started realizing that Perl 5 was going to be living and permanent, and that perl 6 was being shot in the head, and turned into raku.

I have no idea what went wrong there, you really can't come up with a similar analog, at least I can't, I mean, it's like if slackware waits 19 years to do its next release, I mean, how did that happen? Something clearly went deeply and profoundly wrong there, another good case study for how to destroy a project. Luckily some good perl people started to see the problem early enough, but far too late, to lay claim to perl 5, and start moving it forwards again, with a dedicated board and developers, that's now going to jump to perl 7, which inxi is already pretested for, though I should probably double check that now and then. Perl 5.32 introduced some testing modules you can use, and if your program runs with them without errors, it's perl 7 safe.

And the bar to entry is very high, unfortunately, the Perl monks, for example, despite their mantra of there's more than one way to do it, will often note your way is bad, lol... and it's not that welcoming a community, but I don't really blame them, the new generation of script kiddies just aren't very good programmers in many cases, and probably get boring to deal with, but overall, perl monks do a good job. Perl docs also leave a lot to be desired, on their modules, they are very rarely complete enough to where you can just load the module, and then have it all just work, it's taken me days to find one critical one liner required to prep data for the module, when all they had to do was note that trick. All generate high bars to entry, and in today's tech culture, those bars are dangerous.

But perl is very impressive, I think it's safe to say there will never be a better or even equal practical extraction and reporting language. It's speed is shockingly stunning to me, over and over it amazes me, particularly with native regex stuff in huge loops.

3 members found this post helpful.

I'm preparing to open up more of inxi backend data, but I have to go through the files to make sure there's nothing in them that should not be public. But I've already now added a configuration item (FAKE_DATA_DIR) and an option, --fake-data-dir, to let users change where test data is stored. This is a new feature, should have done it long ago, makes it easier anyway, I was hardcoding the paths in each time. There's a lot of them internally.

Over the next week I'll start publishing debugger data files, after checking them, renaming them, etc, though there's no hurry on that end of things.

Those will be found in inxi-perl/data directory, which doesn't exist yet. I wish I could just copy over the entire data directory, but it has to be cleared of any private or personal stuff first. And also there are non dev data types in there as well, which should go in docs/. But given this is a core feature of inxi development, it's something I should have done a long time ago, I just never got around to it, or really thought about it.

I'm not skimming your posts anymore btw, just selectively quoting some things. Anyways, I don't really have a proper right to comment on these things as I'm not into programming (and not young anymore). But I've looked at many things and studied a bit here and there and made some base impressions. My comment on Python was mostly a response to you about everyone just wanting things done easy and sloppy, but also from a user perspecive that I don't like Python and some of the methodology.

I know Java is one of the best languages to get yourself a job, but it's completely unappealing to me. Plus I know that C++ is a decent/good language in the job market. Anyways, I'm too old for that now, but I do have a couple of C programming books on the shelf, and that would be where I would put my effort if..., and then C++ ofcourse. From what I understand you said, if you already know those or at least C, then Perl would not be so tricky to learn?

From what I remember, Perl has been around forever, and am I wrong in thinking it had more of the type of role back then that Python has now?

Maybe it's just a feeling, maybe I'm completely wrong, but Perl looks quite reasonable and solid and with good methods behind it. Is it wrong of me to comparing it to Python, and perhaps saying it is the "good version" of such a thing? Is that the case even with GUI things? I could ofcourse just check on wikipedia or something, but if I'm thinking correctly, Perl is more objective oriented and perhaps also more backend oriented?

I'll check now anyways, I'm too curious. But it's been interesting reading

I checked, and yes, it's exactly what I thought, tesla uses python for prototyping, and c/c++ for actual programming the real stuff, the cars, the datacenters, the machine learning training stuff, for obvious reasons. Same thing google did and probably still does, though now going to Go, not C/C++. To my surprise, they use js/css for their car interface, which shouldn't surprise me, but it did, but it is responsive to input, but it's super inefficient and slow.

Perl has been around forever, that's one reason it's so insanely fast, anything written in the 80s for 80s hardware is going to carry that legacy of caring about every bit and byte of ram/memory you use, every cpu cycle, etc.

Perl was made 1987, designed to be a glue language that would replace many things you might have used sed, awk, and C for previously, mainly as a real sys admin. As someone who has done too much sed and awk, I can say that was a very good decision, lol.

Perl stabilized somewhat after 5.000 came out, I've never seen or used pre 5 perl, at least not that I'm aware of, but after 5.08, you can, and I do, write perl that runs on 2005 operating systems, with 2005 perl 5.008, and modern ones, with 5.34 > 7.0 perl, as long as you don't let modern features slip in, which I do now and then by accident. But you never need to use them.

When I was picking which version to go back to, it was mainly based on what Redhat shipped with around 2005, and Debian to a lesser extent, idea being that a sys admin could ssh into an ancient server that's been running ever since, and get a full info report. There's a lot less data with 2.4 kernel, due to 2.6 opening up a lot, and a lot of core tools improving, like lspci, but everything roughly works with 2.4 kernel. That's the limit though. I have in the docs when each distro introduced each perl version, and it took a LONG time before 5.008 hit most of the main distros, many years after release of 5.008.

I'd say it's definitely wrong to say Perl is more object oriented, quite the contrary, my understanding of both js and python is that for them, everything is an object, and can be anything, a scalar, an array, a hash, an object, which is as I understand it one reason python is so slow, since anything can become anything at any point, python has to do more work to figure out what anything is at every step, thus the ease of prototyping, and the poor performance.

Paul Graham, who wrote the influential article 'great hackers', noted that of all great hackers he knew, only one used java, and he worked for Sun, making java, lol. Otherwise java is a corporate language, and your understanding is the same as mine, nobody ever does java for fun, they do it for a job, or to learn it, so they can do it for a job. In other words, avoid relying ever on java based FOSS code, it's likely the project will be dropped when the person gets the job they were practicing to get, and nobody will take it over, since nobody does it for fun or free.

http://www.paulgraham.com/gh.html

Not much has changed since he wrote that in 2004, which is unusual in tech. The only dated references are to Cobol.

I would say you're slightly off, not wrong, on how Perl was used, it was made for and by sys admins who needed a more powerful tool to do sys admin, but didn't want to get into writing a C program to do whatever. That's I think why it kind of jumped in to fill the void when the internet hit, but I never found Perl to be that great as a web development tool, unlike some somewhat snobbish critics, I have always appreciated PHP, there's a reason it took over the market from Perl, something Perl never adjusted to. Though I have started using Perl for certain backend stuff for work now, it's far, far, far, far superior to shell scripts.

Stretching slightly, since the web was built on Unix initially, we all are used to unix paths in web URLs, so Perl was kind of the tool that could be made to do web sites. I don't think it was ever the best tool to do that, but it was the one that existed, so it's the one that initially got the most use, and grew the most quickly, but at a cost, horrible, unreadable, unmaintainable, code, and a big learning curve, so big that it resulted in tons of horrible code.

PHP fixed a lot of this by removing the learning curve, you could still, and people did, write bad code, but nothing near as bad as bad Perl, which has often been joked about as being a write only language, somewhat justifiably I think, since Perl simply allows too much terseness, and that creates unreadable code.

There was a formula that said something like, if your program is going to be more than like, 100 lines, or 50, it should be done in a real language, not shell, but I don't agree with that anymore, I think as soon as it becomes non trivial, it should be done in Perl or another long term stable and reliable, powerful, established, language, in other words, Perl. The power and features means you can then extend the logic any time you might need to, and you always need to since you can't predict the future. Even on my old inxi backend tools, I was using long shell one liners embedded in the code, and they hid all kinds of bugs, and when I dumped those, and redid them for the newly released open source tools, suddenly everything was fixed, and worked, and could be made more powerful, it was like uncorking a bottle of potential that had been hidden by cramming the stuff into a shell one liner.

I never agreed with or like the ongoing criticism of PHP, to me, php simply fixed the difficult learning curve of Perl, and made a lot of that potential available to the planet, and we got the world wide web. Amazon I believe is one of the only major holdouts for Perl, but I would be amazed if that continues, I don't know where they would get new developers from honestly. To myself, I always referred to PHP as fixed Perl, before I got into Perl, since I tried to get into Perl before PHP, and it was just too weird for me, and most other users. It was only once I started using Perl for what it excels at that it started making sense to me.

To me, Perl was difficult primarily because to use it well, you have to let it work as close to the bare metal as it can, I was avoiding that because that is MUCH harder to understand and learn. Otherwise I was used to C syntax, what I can't personally stand, and I mean, I absolutely can't stand, is the absurd and tragic notion python has that immensely useful visual aids like (), {}, ;, etc, somehow are too hard to type, and thus, forget about easy visual cues to indicate ends of logic blocks, embedded blocks, ends of statements, and rely on this silly idea of using white space only.

Python and js are so high level that they hide basically EVERYTHING from you, wrapping it in multiple layers of fuzzy userfriendliness, but actually, just slowing everything down, and creating new ways to write bad code. I've done a lot of js, enough to where I'm not surprised when js and python are listed as top two languages, but if I were python user, I would NOT be proud to be a peer of JS, sorry, that's something to be ashamed of, not proud of.

What cracked me up was that the guy who had done the original python debugger module (xiin.py) for inxi, was working commercially, and python was so hard to follow that his company required indicating in comments where statements or conditions or functions etc ended, since otherwise you have no visual cue at all.

That to me is simply beyond absurdity, I can't understand how anyone could have made such a silly mistake. It's not like it's natural language like, natural languages use clear punctuation and formatting to indicate all structure, so python was like made by someone who either could not type, or something else, which I can never figure out. Imagine how stupid what I'm typing here would look if I removed all the punctuation and relied solely on white space to indicate anything? it would be beyond stupid, nobody could read it, yet allegedly python was made to resemble natural language.

That's my biggest single gripe with python, beyond them breaking their language every major release, and how absurdly slow it is, though they are chipping slowly away at that. But why they couldn't have simply added a switch that lets yu use visual cues like ; {}, etc, to make your code readable, that's beyond me, I cannot understand it, it makes no sense. Invest in a few weeks of using a typing program if your typing is that bad, lol.

Not to mention that the common, and hard to believe, but I verify it for myself year in and year out, formula, that a programmer does about 10 logic lines a day, which sounds crazy low, but if you do the math, add in research, bugs, meetings, being sick, headaches, bugs, meetings, emails, etc, suddenly you realize, crap, it's 10 lines a day!

Given that, trying to save a few key strokes strikes me as just plain clueless.

1 members found this post helpful.

The first chunk of data is now opened, inxi-perl/data/cpu, that's cpuinfo samples, the sys/cpuinfo pairs used to develop the big CPU refactor here recently. That was the easiest to clean, and most useful short term.

To be frank, I had never heard about Inxi before, but it seems quite impressive, it even gave me a name for the integrated webcam, haha. I've look up alot of information about most my computers, but I've never come across any actual useful data about the webcam.

I'm always astounded by what I have not heard of, lol, options for cli tools I had no idea existed, and which I've worked around not knowing for years.

inxi -v8 is almost all the output. sudo / doas inxi -v8 has some stuff that requires superuser to get, like dmi data, smartctl data, etc. But I always use non root if possible, and only require root if there is absolutely no other way to get the data. Sudo/root however disables certain things, like X/Wayland data, so to get everything, you have to run both.

I faintly remember being annoyed that I had to open my computer case to find out the motherboard, or scroll through a lot of dmidecode output, and just found that annoying, thus, -M/--machine feature.

While most people won't see it, the ARM SoC stuff, like raspberry pi, is to me what is really amazing, because that data is VERY difficult to get a hold of, it's all nonstandard format for data and location and paths, so getting that to generally work took a lot of work, and a lot of testers and contributors.

I'll be releasing more backend data as I can check it, but there is no hurry there, won't impact next inxi release, which is largely ready to go now, barring some last minute issue or glitch.

I've done a lot of work involving remote access to systems, servers, etc, which helped form a lot of the way inxi works, and the types of data it offers you. The other big chunk is end user support, which I also did a lot of for a while, and I get a lot of contributions and ideas from people still actively involved in end user support, forums, like here, so it's always sort of a balance between the needs of a sys admin and the needs of a support person and the needs of an end user. Most of the graphics stuff, for example, and the desktop stuff, is generally only of marginal interest to a sys admin, but is of great interest to end users.

I also track use online and look for broken or missing data, or problems people have that inxi can resolve in terms of making the data readily available. And also new stuff that is breaking news, like nvidia starting the slow process of shipping a usable foss kernel module for its driver, which depends on your nvidia cpu microarchitecture, etc.

I'm hoping to spend a bit less time on this since there's been a non stop series of releases, all of which require a lot of research and testing and coding, and let it get more back to cruising mode, but there's always something to do, inxi does too much, so there's always something or other that can be adjusted, breaks, needs updating, etc.

And with a fizz, 3.3.17 is now out. For better or for worse.

Thanks for once again helping nail down some corner cases, I'll see how this one does.

There's a bug in 3.3.17, hard to trip, but someone did, 3.3.18 will be out shortly, tomorrow probably, if not today.

Here is the output from an Amd cpu with Nvidia chipset and it does show the legacy info
for the gpu and what the Nvidia driver would be. It looks like it would need the 304 driver
for it. I like that this cpu shows nothing for vulnerabilities.

Attached Thumbnails

 

I'm going to have to double check that, the message said (try --gpu) but that's wrong, you used gpu, that wasn't supposed to do that. Nice machine, I had an emachines too!! I think like 1995 or so?

[Update] Yes it was reversed, heh. Showed try --gpu with --gpu, not without as intended, I know you didn't intend to catch that small bug, but you did, so thanks!

P.S., also excellent timing, since 3.3.18 has to be rushed out, 3.3.17 has a significant bug in it.

By the way, the K8 F+ I could not pin down built years, the IDs were too loose and indefinite for that particular series. I tried to get most of them, but that specific one I could not lock down with any accuracy.

You can also tell that from the process: node range, that's quite wide, indicating a fairly long production run through several process nodes. I think I could lock it down more, not sure, but I couldn't when I looked originally.

your welcome, I thought it was odd also that it mentioned try --gpu. That cpu is based of the Lima core at 0.065 micron.
The cpu has 2005 actually printed on it. My Amd 2650e also has 2005 on the cpu.

Attached Thumbnails

 

For some reason, cpu-world.com and wikichip both are very weak on these two series:

Model: 4|5|7|8|B|C|E|F|14|15|17|18|1B|1C|1F - arch K8
Model: 21|23|24|25|27|28|2C|2F - arch K8 rev.E
Model: 41|43|48|4B|4C|4F|5D|5F|68|6B|6C|6F|7C|7F|C1 - arch K8 rev.F

All these were 65-130nm process, but I have not found a more granular breakdown of that era of k8 cpus.

It's done by hex model ID, all family F. that's the only AMD series I couldn't pin down.

Your case is 7F, which you know the year of, but I can't find this data for all of them, if i could, I'd make those 3 categories more granular and split them up.

Main problem is no site has all this data together, it requires the hex family/model ids, that's what inxi uses to id them, and only cpu-world.com has those consistently, but you have to look them up one by one. wikichips sometimes has them, sometimes not. In the case of AMD, that was how they listed that k8 series.

I've updated the AMD IDs to note 7F is 65 nm and 2005 built year, but that leaves a lot. Also note finding the model ID release years is hard, you can often find the announce date for it, or the release date, but it's less common to find the first introduced date and model end date. When I can't find it clearly and accurate, I'm leaving it blank, since I think it's better to show nothing than to show something that is misleading or wrong.

However, note that I fully expected the gpu and cpu legacy ids to be filled in over time, I did the best I could, but I couldn't spend forever on it, and it was just very difficult to find the data in any reliable or consistent place