> This has been my experience with the Linux community for 26 years.
I read through that post that elicited those comments that you have a problem with. At the end of a long list of complaints, it says: ".....yep, just as user friendly as I remember."
Nowhere does that post request help, and with that last comment, is clearly intended as a disparagement of Linux, not a request for help.
Then, you are turning around, and cherry picking responses to highlight the negative responses to a negative post, and disparaging the Linux community while ignoring the helpful responses.
Half those aren't even remotely harsh. Saying the raspberry pi wasn't designed to be mained is totally reasonable, what possible objection do you have to somebody saying that?
I understand pointing out that an upgrade failure should be expected when Ubuntu tells you that upgrades won't work, but I don't agree with calling the Pi a "device for experimentation". Not only it's used for serious applications in industrial settings, but some products are sold as... personal computers:
> Raspberry Pi 500
> The refined personal computer.
> A fast, powerful computer built into a high-quality keyboard, for the ultimate compact PC experience.
That my complaints trying to install software have absolutely nothing to do with it being a Raspberry Pi and the experience is identical on any Linux machine.
> Half those aren't even remotely harsh.
....and the fact that people consider this to be the case is more evidence of the Linux community's hostility.
Linux is like Rick and Morty: I don't mind it, but I never want to be associated with its fans.
If you can't take the mildlest of implied criticisms without feeling offended, this isn't a Linux problem, it's a you wandered out of your safe space hugbox problem.
I agree that it is very different from other CAD software, but that is also something I like. When I started using SolveSpace for some easy models, I was a bit lost. But then it clicked, and I really enjoyed the different approach. It is not my main CAD software (build123d is), but I really appreciate the workflow.
I don't think that every oss should try the copy what already exists. The best is when new approaches are tried. The same happened to me when I started using tilling window managers. "Professional" Operating systems don't have that, but I am sure that if more people would try them, many would realize that the workflow fits them better. So, my point is that there is no single best solution in terms of user interface or interaction with a program, and the fact that many people explore and share different approaches with their open source software is something I really appreciate.
The accountability part is what makes me more angry. I get to lose so many (maybe hundreds?) of hours a year because of how bad DB works. Meanwhile the executives at DB get their nice boni each year and absurdly high wages for what they do... which is consistently worsening the train experience year after year. Probably none of them even use the train.
I am always a bit annoyed when the root of the problem is not explained. This is the case most of the time (DB of course). I would really like to have a bit more information. Even if there is nothing you can do, it helps to understand how big or small the problem is. Then you can make a decision based on it. Like getting out in the next station or something.
Just got my Framework 13 last week. I really love this computer, and how it is pushing for upgradability and repairability in this segment. Thanks a lot for creating this computer!
Just got my Framework Dektop a few weeks ago and it works flawlessly so far with Debian 13 install including (shock!) suspend working without issue. :)
It’s really great to see companies focus on improving Linux hardware support.
I just bought a second Fairphone 4 just to play a bit with pmOS. I'm really surprised by the state it is. It's not fully usable as a daily driver yet, but with some work it can get there. Waydroid works also pretty good. Of course, the major problem are banking apps and similar. I hope that some progress can be done in this direction. And, who needs working audio, if you can have python and git in your phone!? :P
I made a partition for Nix on mine so I have all the tools I need while not relying on Jolla to package things (the installable package list is quite barren). My audio works from the speakers, but the patches to make the headphone jack (something you Fairphone users no longer know of :P) work won’t come til the next release. For banks, I just use cash or log into the website on my laptop if required—while I will refuse goods/services that require an apps to the fullest extent possible (couldn’t get around TicketMaster which was a real blood-boiler beyond just the “phone required” aspect).
Yes, I think that just trying to use services that don't require special mobile apps can get you a long way. It is sometimes difficult, but now I'm beginning to move more in this direction :)
It’s the same as unGoogling your life where you can slowly start moving off one service at a time & make sure new ones you use are open or at least otherwise ethical.
Did you test apps that need sensors and notifications? If I want to run an OpenStreetmaps apk (there's no good way to run OMS on Linux natively), do I get GPS and compass heading? Do I get turn-by-turn navigation? Even if the app is in the background?
I'm always amazed by people doing reverse engineering of some country formats. There's a binary format that I've been wanting to reverse engineer, but I don't know exactly how to start. It's for the result file of a proprietary finite element program. Could anyone point me to some resources and also what are the basics that I need to learn to achieve this?
(a) you reverse engineer the application writing or reading the file. Even without fully understanding the application it can give you valuable information about the format (e.g. "The application calls fwrite in a for loop ten times, maybe those are related to the ten elements that I see on the screen").
(b) you reverse engineer only the file. For example, you change one value in the application and compare the resulting output file. Or the opposite way: you change one value in the file and see what happens in the application when you load it.
The most important resource you'll need is a hex editor that can let you drop at a cursor and see what the value is at the cursor for all the basic datatypes (u8/u16/u32/u64, float, double, at minimum). Something like 010 Editor or ImHex.
If it's a really simple format, since you appear to have the ability to generate arbitrary file contents using the program, you can get some mileage by generating a suite of small contents with few changes between them. I reverse engineered the DSP sphere blueprint format by generating a blueprint with one node, then the same node located elsewhere, then two nodes, then two nodes and one frame between them, etc. But this process is really only possible for the simplest formats; I'd gander that most reverse-engineered file formats are heavily based on decompilation of the deserialization code.
A lot of binary file formats end up being some form of "container" format--essentially, a file contains some form of directory mapping an item ID to a location in the file, and the contents of that is in some other binary format. It's worth first checking if this is the case, and matching against known formats like ZIP or HDF5.
ImHex will tell you if it's compressed. Do you understand data structures? Floats, all those data types?
I'd suggest looking at a format like msgpack to see what a binary data format could look like: https://msgpack.org/
Then be aware that proprietary formats are going to be a lot more complicated. Or maybe it's just zipped up json data, only way to tell is to start poking around at it.
The way I do it is looking for markers. Most files have some kind of magic number in the beginning. So these can valuable to recognize.
The next part is always looking into the values of 32 bit or 64 bit integers, if their value is higher than 0 but less then the files size they often are offsets into the file, meaning they address specific parts.
Another recommendation is to understand what you are looking for. For games, you are most likely looking for meshes and textures. For meshes in 3D every vertex of a mesh is most likely represented by 3 floats / doubles. If you see clusters of 3 floats with sensical values (e.g. without an +/-E component) its likely that your looking at real floats.
When looking for textures it can help to adjust the view on the data to the same resolution of the data your looking for. For example, if you are looking for a 8bit alpha map with a resolution of 64 x 64 then try to get 64 bytes in a row in your hex editor, you might be lucky to see the pattern show up.
For save games I can only reiterated what has been mentioned before. Look for unique specific values in the file as integers. For example how much gold you have.
I used these technics to reverse engineer:
* Diablo 2 save games
* World of Worcraft adt chunks
* .NET Assembly files (I would recommend reading the ECMA specification though)
* jade format of Beyond good and evil
Ah yes, invest in a good hex editor of course. For me Hex Workshop has been part of this journey.
The bare basics are working with a hex editor and understanding data types - ints, floats, null-terminated strings, length-prefixed strings etc.
I'd recommend taking a well documented binary file format (Doom WAD file?), go over the documentation, and see that you manage to see the individual values in the hex editor.
Now, after you have a feel for how things might look in hex, look at your own file. Start by saving an empty project from your program and identifying the header, maybe it's compressed?
If it's not, change a tiny thing in the program and save again, compare the files to see what changed. Or alternatively change the file a tiny bit and load it.
Write a parser and add things as you learn more. If the file isn't intentionally obfuscated, it should probably be just a matter of persevering until you can parse the entire file.
Thanks. That is kind of what I imagined. But I am not good at understanding the information from the hex editor. Reading the article I was a bit lost with the terms like little-endian and thought that that might be someone important concept to know for the task . I guess that that is what I should learn first.
As someone who has reverse engineers hundreds of random file formats of all kinds over the years, the comment that suggests understanding the code is generally spot on.
You can basically divide the world into read/write/write-only formats and read-only formats.
For read/write/write-only formats, usually the in-memory data structures were written first, and then the serialization/deserialization code. So it almost always more useful to see how the code works, than try to just figure out what random bytes in the file mean. A not insignificant percent of the time, the serialization/deserialization code is fairly straightforward - read some bytes, maybe decompress them, maybe checksum them and compare to a checksum field, shove in right place in memory structure/create a class using it, move on.
Different parts of the program may read different parts of a file, but again, usually a given part of the deserialization/serialization code is fairly
understandable.
Read-only formats are scattershot. Lots of reasons. I'll just cover a few. First, because the code doesn't usually have both the writing and reading, you have less of a point of reference for what reading code is doing. Second, they are not uncommonly memory mapped serializations of in-memory structures. But not necessarily even for the current platform. So it may even make perfect sense and be easy to undersatnd on some platform, but on your platform, the code is doing weird conversions and such. This is essentially a variant of "the format was designed before the code". Lots and lots more issues.
I still would start by trying to understand deserialization code rather the format directly in this case, but it often is significantly harder to get a handle on.
There are commonalities in some types of programs (IE you will find commonalities between games using the same engine, etc), but if you are talking "in general", the above is the best "in general" i can give you.
One other tip - it is common to expect things to be logical and make sense - you can even see an example in this very article. Don't expect this.
For example, data fields that don't make sense or are broken, but the program doesn't use it so it doesn't matter, checksums that don't actually check anything, signed/verified files where the signing key is changeable easily, encryption where the key is hardcoded or stored in the file, you name it.
Most folks verify that their program works, they don't usually go look and verify that everything written/read makes any sense.
It has been a minute since I routinely did this kind of work, but I have to mention this because it's fun:
You can do something in between reverse-engineering the code and reverse-engineering the format if you can instrument the reader: attach breakpoints on every basic block in the reader, load a file, take a baseline trace of what gets hit, then vary bytes in the file and diff the new trace against the baseline.
It helps tremendously if you have a programming background as usually the developers behind the original format didn't have any need to make things harder than they need to be. Because of this, you can often guess how the format works, aka. "If I was the original developer, how would I do this?"
I am an engineer, but not a computer scientist or developer. I have been using Linux for 20 years and program a lot at work and at home. I think it should be possible, but find it difficult to interpret the hex code. I do have a general idea of how the format should be organized, as it contains mostly geometric data and associated results.
If you make a lot of slides with latex, then it is definitely worth it to try typst. I have a lot of presentations in latex for lectures and such things, with many animated tikz figures. But the compilation times are huge. At some point it is very time consuming to iterate. With typst, it compiles so fast that you don't have to fear to start a compilation. I finish my presentations much faster now.
Cetz has been working very good for me. I was really unsure that it could replace tikz for my applications. But apparently, as long as you have good geometrical primitives (lines, rectangle, circles, etc) you can do a lot. Also it is much nicer to program and make real functions with typst. It is true, the typst options to replace beamer are still not quite there in comparison, but they are definitely in a very useful state. See for example typst-presentate [1].
One thing I'm missing when making slides with typst is the ability to show short videos or animated gifs. Although to be fair this isn't easy in beamer either.
Typst can actually include gifs, but they don't move for me. I have some hopes that perhaps one could make slides straight in html which could alleviate the issue.
I was very surprised that it worked perfectly in my 10-year old notebook. Normally, nothing this fancy is playable in a web browser for me. The CPU was about 20% (I only have two cores, 4 threads).
This looks super nice! That is kind of the interface I wish FreeCAD could have. I am more the type of person who likes to use a python interface to create parametric models, but this is really cool!
Anyone knows what is the status of Truck [1] in this regard. Are they going to implement an open-source CAD program with their CAD-kernel? That also looks like a promising project.
Thanks for clarifying cadmium's status and offering your take on the state of truck and fornjot. So, what happened with cadmium? Is Truck just too primitive to build on top of so far? It looks like both of these kernels are actively being developed, what do you think of their rate of progress?
No idea where truck is going, it'll take me quite some time to tinker with CAD I think, it left me quite a bitter taste...
Fornjot seems to be doing good, I'm donating to them and I get regular updates (you should too!). Still, there's a long, long road ahead
If I were to do this all over again I'd either go the OCCT route (like chili3d or zoo) or solvespace. they're both "lacking" kernels if you compare them to the commercial ones, but I think there's enough "market gap" for makers that would prefer a sustainable CAD format instead of perfect fillets (and IMO freecad is not the solution).
Keep in mind though that my efforts where laser focused on non-math stuff. From what I gathered from my time in cadmium, b-rep kernels are hard in an unsustainable level. Browser level unsustainable. I just hope that out of seer necessity we'll find another way to solve the CAD problem, instead of a b-rep kernel
I think that the tools are not will organized, and I always have problems finding the tool I need in the menu. The concept of having different workbenches does not work good for me, as often I am looking for a tool and then realize I am in the wrong workbench. But it is not always clear why something is in a workbench and not in the other, and there are duplicated functions in some workbenches. Also, the fact that it does not support Wayland makes everything look blurry in hdpi screens. I like that it has a good python
API though, but the documentation is a bit lacking. However, the different workbenches also sometimes complicate the use of the Python API. I like e.g. how build123d works.
FreeCAD interface needs to take a lot of pointers from paid CAD programs, this Chili3D interface is quite close, larger icons in ribbons at the top of the screen with clear definitions
There's an active knee-jerk hostility in the FreeCAD community to any user problem that even hints that it might involve a comparison to proprietary CAD. I've had "FreeCAD isn't Fusion and you shouldn't expect it to behave the same way" thrown at me when I've been discussing something bone-headed FreeCAD was doing.
reply