OSDev.org

Prochamber wrote:On a well documented project this is easy, just run './configure, make, make install

One thing about this. The portability of programs has been mentioned quite many times here. If we write portable C, it is going to compile on several different systems. The code itself I mean. Of course, there are usually more than "standard libraries" that make this whole thing more complicated. What about the build system?

As an example again, the "hello world" program that uses only standard C library. However, that program can be much more complicate than this and they actually could do something useful. Packed in "single-source file". It will be exremely portable. If we had this "making programs portable ./configure && make && make install" building system, it really means that it is portable between different variations of Unix. Runs very bad on Windows. Cygwin-like systems can work-around this but it is quite a big "layer" and does not make things as simple as they could be. Why do not we just run the whole "Unix" on virtual machine in that case? Is this kind of portability "real"?

Of course I can compile the source code manually. It will be quite laborious if source code is scattered around.

Hi,

Prochamber wrote:

Kevin wrote:It's inherently hard to send multiple files, but it's easy to send a single file

Sure, if you have multiple files you need to put it in an archive and that requires additional software to setup. If you're using Windows, you'll probably want to create a .zip. On Linux a .tar.gz is more often preferred, which isn't supported out of the box on Windows.

A generic archive file format isn't ideal - if we're "inventors", we can do better. In addition to having a list of files/units/objects/pieces (which is all you'd get with something like tar or zip); you'd want some extra metadata (if the source code is an application, driver, flat binary; copyright information, etc); plus a little information about each of the files/units/objects/pieces (which language, etc). You might also want information about sections and their attributes.

You also want indexes for things like where types are defined and where symbols (functions, data, etc) are defined, as this improves performance. For example; when you open the file in an IDE, the IDE may read the headers and indexes during startup, and only read other parts of the file on demand. If you click on a function call (to see the function's code) then the IDE would use the index to quickly find the function without slow/silly searches (and without the IDE reading the entire file and building its own indexes during startup). If you stop using "plain text" there's other benefits too - instead of having names (for variables, functions, etc) in the source code itself you can have the names in the index instead; which reduces file sizes and means that by changing the name of something anywhere it's automatically changed everywhere (no need for "search all the source code for each occurrence of "foo()" and change it to "bar()"). The other benefit (compared to languages like C) is that the compiler can use the indexes instead of requiring declarations; which makes it easier for programmers to write source code as they don't need to care about writing/maintaining declarations just to make the compiler happy.

Antti wrote:

Prochamber wrote:On a well documented project this is easy, just run './configure, make, make install

One thing about this. The portability of programs has been mentioned quite many times here. If we write portable C, it is going to compile on several different systems. The code itself I mean. Of course, there are usually more than "standard libraries" that make this whole thing more complicated. What about the build system?

I think it's important to determine what sort of "portability" matters. I only care about portability between one version of my OS and another version of my OS (e.g. between a 32-bit 80x86 version of my OS and a 64-bit 80x86 version of my OS, and maybe an ARM version later); which gives me a lot more freedom to design what I want.

Some people might care about porting code between different OSs (e.g. between Windows, *nix and their own OS); which involves supporting suitable tools and libraries on each different OS (in the same way that 'make', linkers, C compilers and SDL library have all been ported to many different OSs). This gives the same "freedom to design what you want" but involves a lot more work.

The other type of "portability" is being able to port projects from one environment to a completely different environment (e.g. from a common C/C++/POSIX environment to a Java/Netbeans/Eclipse environment or to a VS/.NET environment). This is compatibility between environments and not really portability of source code; and in my opinion it's the least important (e.g. I haven't seen many Java developers complaining that they can't use GNU's "autoconf" or Microsoft's "CLR Profiler" for their Java projects, even though most of these Java developers are using Windows and these tools do support Windows).


Cheers,

Brendan

Antti wrote:As an example again, the "hello world" program that uses only standard C library. However, that program can be much more complicate than this and they actually could do something useful. Packed in "single-source file". It will be exremely portable.

The problem is that for most serious applications, the C standard library is simply not enough. You can't write a GUI program with it (nor a nice TUI, as a matter of fact), and in cases where you don't want that, you usually want to access more low-level details of the OS. Leaves you mostly with command line tools that work on one or more files and somehow process it, maybe do some calculations, and produce another output file (or write everything to stdout).

And of course, just using the C standard library doesn't guarantee that your program is portable. There is still implementation-defined behaviour in the language that the program may be using (and that a configure would check), possibly even undefined behaviour if you're a bay boy, there may be bugs in the libc implementation, etc.

If we had this "making programs portable ./configure && make && make install" building system, it really means that it is portable between different variations of Unix. Runs very bad on Windows. Cygwin-like systems can work-around this but it is quite a big "layer" and does not make things as simple as they could be. Why do not we just run the whole "Unix" on virtual machine in that case? Is this kind of portability "real"?

You're mixing up portability of the application and portability of the build system. While bash scripts and Makefiles need additional software on Windows to be run (so what? Just install it.), the resulting program doesn't require these tools. You can even cross-compile for a Windows target on a *nix build host if you prefer.

Of course I can compile the source code manually. It will be quite laborious if source code is scattered around.

You'll also have to manually execute the scripts, creating things like config.h and all. But I guess in theory you can. There's just no reason to do so.

Leaves you mostly with command line tools that work on one or more files and somehow process it, maybe do some calculations, and produce another output file

Files?

Wash your mouth out!

Ah, right, let me retry: Leaves you mostly with command line tools that work on the one and only persistent object and somehow process it, maybe do some calculations, and produce a new part to be appended to the persistent object.

Better?

My post that contains the quote "We have persistent objects, they're called files" was not good. That was just one example of those inventions the "inventors" made. Soon after that I wrote

Antti wrote:What do you think the early inventors might be thinking now...

was not very clear. I should have made another post for that because I was not referring to the previous paragraph. I just started wondering in general what the early "inventors" might be thinking about their work and the high-valued status of those inventions. I was not meant to point this to the "files" in particular.

I do not think the persistence of files is a problem. Terminology is fine too. "File" is a common concept and we understand it. I did not mean to make this persistence object concept any big deal. However, I do not want to ban making fun of it! The original idea would have used files albeit a single one, a plain-text file.

Because I am a "learner", I have learned during this thread. I do not think the original idea solves anything. We really need to do something more than that. I have been told here that "if it ain't broke..." but I still think "it is broken".

I just started wondering in general what the early "inventors" might be thinking about their work and the high-valued status of those inventions.

Well, there's a guy that died this week who I guess was pretty proud of the status of his invention (albeit hardware rather than software). That something was invented a long time ago doesn't have to mean that it is irrelevant today. The idea of files fits into the same category as the mouse for me.

As does the wheel.

Hi,

Antti wrote:Because I am a "learner", I have learned during this thread. I do not think the original idea solves anything. We really need to do something more than that. I have been told here that "if it ain't broke..." but I still think "it is broken".

I wouldn't necessarily say that existing tools are fundamentally broken. To me the question is whether or not there's a better way For example; once upon a time people used paper, quill and little pots of ink; which worked fine (wasn't broken). I'd assume these people thought there was no better way, simply because the pen hadn't been invented yet.

iansjack wrote:

I just started wondering in general what the early "inventors" might be thinking about their work and the high-valued status of those inventions.

Well, there's a guy that died this week who I guess was pretty proud of the status of his invention (albeit hardware rather than software). That something was invented a long time ago doesn't have to mean that it is irrelevant today. The idea of files fits into the same category as the mouse for me.

As does the wheel.

For "files" (or more specifically, the idea of associating a name and attributes to a collection of data), I can't think of any way to improve the basic concept and suspect there is no better way. Of course file systems (the way files are managed/stored and the amount and type of metadata/attributes), and the contents of files (file formats) are more than just the basic concept of "files".


Cheers,

Brendan

Hi,

iansjack wrote:Well, there's a guy that died this week who I guess was pretty proud of the status of his invention (albeit hardware rather than software). That something was invented a long time ago doesn't have to mean that it is irrelevant today. The idea of files fits into the same category as the mouse for me.

As does the wheel.

As for the mouse, I really believe that it isn't going to be as relevant as it is today. Firstly, there is the advent of touch-screens, which certainly would change stuff; of course, some still despise using a touch-screen as a method of UI for desktops (see: hatred towards Windows8).

As an alternative, there is technology like Leap and Kinect (for PC). Note that with leap, unlike with touchscreens, you don't have to keep your hand hanging in air -- you could configure leap to treat, for example, your table desk as the "input" area, so that you can use your hand just as you used your mouse. Note that it will have many benefits, like being able to make gestures -- you could flick your index finger and thumb to delete some file, or use your thumb and first two fingers to rotate some image, and so forth.

Leap doesn't completely plan to replace the mouse, neither does it boast of being particularly for that area. It doesn't completely revolutionize input, either; as of now, you'll still be faced with old paradigms like the pointer in WIMP. I just believe like technology like that would slowly, yet steadily, make older technology adapt with the newer times.

Of course, this all wasn't particularly about the idea of single files v/s multiple files -- I don't think I can talk much about the benefits and usability of the former, unless I see a demo/prototype made by either Antti or Brendan. It was simply saying that once in a while, refreshments to older paradigms doesn't hurt. That doesn't mean that something must be first "broken" before you attempt to fix it; IMHO, you can't figure out if something was broken until you see a better model. For example, before the wheel came about, people must be using horses or something (my history is a bit poor..) for transport. Using horses for transport looks in no way broken to me, unless someone came along and showed them that you could put two wheels on a wooden plank, attach it to two horses, and then enjoy bigger space. Similarly, in the future, someone might replace wheels by some type of magnetic field to allow hovering cars -- they'll say that the old wheel was broken, because it might've gotten damaged soon, leading to accidents and such. In a more distant future, someone might replace that by teleportation -- "obviously, you don't want to have minor influences in your cars magnetic field from others, and get in an accident due to that." In an even more distant future, someone might go all Zen and say that we don't need transportation at all! Similarly, before electricity came about, whatever alternatives existed for current electronic devices (e.g. earthen pot instead of refrigerators) weren't "broke" either -- the alternatives we developed were simply better. I think a better version of the saying could go by "if it ain't broke, you ain't trying hard enough to fix it."

Regards,
Shikhin

Hi,

Brendan wrote:I wouldn't necessarily say that existing tools are fundamentally broken. To me the question is whether or not there's a better way For example; once upon a time people used paper, quill and little pots of ink; which worked fine (wasn't broken). I'd assume these people thought there was no better way, simply because the pen hadn't been invented yet.

Heh, Brendan beat me to it.

Regards,
Shikhin

Antti wrote:I have been told here that "if it ain't broke..." but I still think "it is broken".

I tried to soften the word "broken" by using quotation marks. I definitely do not think that all old things or less-advanced methods (be it quill and and little pots of ink) are broken. However, things like "hacks fixing previous hacks" that add up are.

The quill and little pots of ink can be a good example. What if, instead of inventing a printer, we have made a robot that carefully drops the quill in ink and then start writing the text we want to print. It would be nice I agree. We would have made a nice work-around to keep the old way of printing texts. What if someone says that forget the quill and little pots of ink and do not try to improve that old method anymore? Try something totally different.

What I am saying is: the quill and little pots of ink are good per se. Endless modifications and upgrades will make them broken. Something like this has happened here. "Writing software" has been evolved too long without never starting from scratch.

What occurred to me is that the "file" is basically untyped, just as any data access in assembly lacks types. We can do better than that by starting to make the entire filesystem mime-type aware in some fashion.

Combuster, you have some ideas. If using filename extensions, we have a sort of way of identify the file type. Quite a weak way, I think. If we do not have them, then we rely on recognizing the type when looking at the content. This is not very standardised and it requires quite complex code to recognize even just the most common formats. Unknown formats are left unknown without any idea what they are.

If the type is somehow "outside" from the file content, then we definitely could have a unified way of identifying files.

Hi,

Antti wrote:What I am saying is: the quill and little pots of ink are good per se. Endless modifications and upgrades will make them broken. Something like this has happened here. "Writing software" has been evolved too long without never starting from scratch.

I'd like to reiterate my point, a bit. It isn't always about "fixing endless modifications and upgrades." In fact, it isn't always about "fixing" anything. Sometimes, you've got to invent, innovate, just to improve something old. Note that "improving" something doesn't imply that the said "something" was broke -- it simply implies that you can do a better job at it. I personally believe that ANY type of "fixing" only results in more borked up solutions; you end up with massive hacks, and history has proven me right. On the other hand, with improvement: that's how the pen came to be, that's how the wheel came to be, that's how the refrigerator came to be, and that's how new technology will always come -- not trying to fix something, but trying to improve something.

Regards,
Shikhin

You are right. If thinking about us here, we can put some effort into this. I said that "if it ain't broke..." is not so valid here. People who are interested in OSDev should be more interested in seeing the foundation than the actual "skyscraper". If it is possible to create the skyscraper at all, it means that the foundation must be pretty good already. It is a real challenge to do improvements on that. Notably, the resistance to change is huge because big changes may unbalance the foundation.

When OSDev people see the skyscraper, they start climbing up on the second floor of it. There is an elevator that quickly take you to the top. The site right next to this does not look very good. There are some engineers planning an improved foundation and structure standards that could made a taller and more stable skyscraper. It is not interesting at all. "What a waste of time", they think. "We are on the top already".

This post is almost funny to me, do not take this too seriously. I am not claiming that I could design the foundation for the skyscraper. I am still struggling with basic things. However, I want to make sure that the buildings are built on steady ground. Even the small one I am building.