/tech/ - Technology★

# Proposed guidelines

We need to organise in some way to achieve anything with the project. We need to learn from the mistakes of the Linux project and prevent things like CoCs or corporate/government infiltration.

Therefore, I propose the following guidelines (which are OPEN FOR DISCUSSION):

## Project

1. All code written should be licensed as free software, preferably GPL3, to prevent *Embrace, Extend, Extinguish*, Pivoisation, and the like. I am not sure if AGPL3 has any merits over GPL3 if used for an operating system. If yes, then I prefer using AGPL3. Even though the version 3 protects against rescinding granted licenses, which is crucial for destroying Linux after the CoC, since we prepare against CoCs beforehand, there should be no need for not using version 3.

2. The OS should be architecture-aware, but provide a well-chosen amount of abstraction. This is an important part: To specify a well thought-out API that is modern and reasonable. With the goal in mind to create a lasting platform, we should take our time to carefully consider how the OS should be designed.

## Anonymity

1. Contributors should use aliases, not only to prevent attention whoring, but also to protect against surveillance: There cannot be any black mailing if nobody knows who is contributing.

2. Contributors should make the commit metadata (time, email, etc.) unusable.

## Code Organisation

We should organise in a decentralised manner, to avert attacks. I propose the organisation into feature forks, where a feature fork is a fork from an early stage of the project without any other features. To get the whole project code in one place, multiple feature forks can be merged. This is tedious, but highly resilient to centralised control.

1. To prevent centralisation of the codebase into a single repository (see Linux), I recommend that there should be many forks of the platform: After a certain base point, separate features should be worked on in separate forks, which then have to be merged to create a whole. This means that the whole project will be split into sub-projects. This may seem silly, but isn't: The current Linux spectacle has shown that having a monolithic main repository will lead to potential abuse by admins (refusing pull requests by blacklisted contributors etc.). In my proposed system, there is no main repository, every part of the system can be maintained by everyone separately. Of course, this will create an overhead when trying to find the latest forks for every feature, but, as I see it, this is the only way to prevent a dangerous centralisation of administrative power that could be used to destroy the project (again, see Linux). If we manage to master this form of organisation, we will have a decentralised, robust developer community that cannot be controlled in any way (short of personal threats).

2. Ensure that all feature forks are as early into the history as is reasonable. If features share as few ancestor commits as possible, it is easy to revert changes, and the code is kept decentralised. Imagine forking a 3D accelerator feature fork to create an audio driver feature fork. This would make the audio driver only usable in conjunction with the 3D accelerator, which bloats the system unnecessarily. Feature forks should not fork from features they do not rely on.

3. Prioritise a simple working set of features over fancy features that are not crucial. The earlier the platform can be used to actually develop applications on, the earlier we can enjoy it and notice design choices to be reconsidered. Fancy features such as 3D acceleration are not important early on and should be worked on later.

If you made it this far, congratulations.

I would like to hear what you think of this. Suggestions?

Also, we would need some kind of name.

>I would like to hear what you think of this

I would like to hear what you're going to contribute to this project besides ideas.

l o g o

o

g

o

>>1000381

I would obviously also code, I forgot to mention this but I have much programming experience and know how to program an OS.

>>1000381

This thread is currently an attempt to form a consensus on goals and to create a group to launch the project with. I am not pretentious enough to just make rules and expect everyone to follow them.

>Organising non-CoC quality OS.

<fork CoCfull OS

<remove CoC

<release as CoCless OS

< ???

< profit

>>1000390

That would be the easy way, but I think we can do better than that. You might as well just use the latest versions of Linux before the CoC, but that's not the point.

>>1000391

>we can do better than that

That's where you are wrong kiddo.

>>1000378 (OP)

>Validating CoC by treating it as meaningful

playing on their terms you will never win

Instead you must tell them CoC is meaningless bullshit from the fantasy of their own imagination, and has no purpose in your OS.

>>1000397

I don't think so, there must be at least a few able guys on this board, which is who I am trying to reach using this thread.

>>1000406

I never said that it was meaningful, if you had any reading skills you would know that I am on the anti-CoC faction.

However, as the CoC gets enforced on the Linux project, it is a very real thing, and should not be overlooked based on "heh, I bet it will not have any effect xD".

>>1000417

Whatever, anon. I did not try to, nor did I intend to, get ALL of /tech/ to be OSDevs. And if you put in effort, it is not impossible to do, even on your own. However, I am convinced that a collaboration of a group of developers can produce higher quality code and architectures.

And don't meme your way out of responsibility or strawman me with some simplistic opinion. In the end it is everyone's responsibility to create a lasting, uncucked OS that is not controlled by trannies and megacorporations.

>Since the introduction of the anti-meritocratic "Contributor Covenant" CoC

By trying to be neutral and not standing without any shame for the truth (that equality is a false god, trannies/faggots are mentally ill and the only remedy that can restore their almost inexistent dignity is euthanasia and a lot more not-feels-good trivia), you've already fallen for their trap.

>>1000423

I don't give a shit about the mental health of other people, I have nothing to do with them. That is why I don't care whether they should be eliminated or not. I also don't think that this hatred against trannies and other mentally ill people is what should be the glue of our project, but the authentic desire to have an OS that is not controlled by big corporations or subject to someone's politics and mind games.

I'd like to see a truly modular kernel, composed only of a "hypervisor" that just loads and hotswaps the kernel in case it needs an update, a "system" or framework which just provides communication to the different modules, and modules which provide the actual functions and have standarized API. You could say this is an exokernel, but I wouldn't be against at optionally running it all in kernel mode with a compile time flag.

I just want to see an OS where I can easily fuck any kernel module's shit up by removing a single reference to i. in a config file, then replace it with an equivalent one which uses the same API.

>>1000429

Remember LibreBoot? Trannies are ticking timebombs, eventually something insignificant is going to make them snap and they will take down the entire project along the way. Humans work as a whole, and if one part is rotten it will spoil the entire person. Just look at furries, they are not content with drawing their shitty fetish art, they have to spread it everywhere and ruing any place they go to.

>>1000378 (OP)

Since Linux is just the kernel, why not use a different kernel instead of an entire OS? Hurd is still waiting to be finished.

>>1000433

This is very similar to what I was thinking: Although my terminology is a bit sloppy, these modules would be the feature forks I spoke of. So to say, you have a basic minimal kernel, and anything that is not completely essential for the module system is then separately developed. I also sincerely hope that there will be multiple versions for every component, and a healthy sense of competition.

The problem with standardisation is, there needs to be a consensus, but since we are anons here, it is hard to get a real consensus, so it might happen that there are slightly differing interfaces (+/- some functionality). So this might not be easy to achieve, but I guess it will be possible to get at least an almost-consensus on what an interface should look like.

>>1000438

> Remember LibreBoot?

No, I do not know what happened there, but I can imagine some scenarios.

I think that since there is only a decentralised organisation and no single rulemaker, no set of participants can fuck everyone else over, especially if we develop under GPL3 with no-revocation clause. Even if at some point trannies get into the project (we would not immediately know since they are anonymous), there is nothing they can do to the rest except fork the project and ruin their own forks.

> why not use a different kernel instead of an entire OS? Hurd is still waiting to be finished.

I did not look into Hurd yet, but I do not know whether they are truly modern, i.e., did they just implement POSIX-compliance or did they think up a new standard / interface that is up to date for the next decades?

>>1000429

>I don't give a shit about the mental health of other people, I have nothing to do with them.

>the people around you (aka your society) can't influence your life

Must be nice being an adolescent lolberg.

I know we jerk off to how terrible the CoC is here, but you cannot make an new OS where the only feature is that it doesn't have a CoC. Linux will always win purely because it has more existing software.

>>1000378 (OP)

>I made the effort to format this in markdown, so feel free to enhance your reading experience.

8ch has it's own formatting. You can see it if you click on [options] up at the top, then "customize formatting".

In general, I suggest you lurk moar, and recognize that the only way projects get done around here is by having one sperg do all the work, and have everyone else tell him what features to have. You can either be that sperg, or give up now.

>>1000455

>but you cannot make an new OS where the only feature is that it doesn't have a CoC.

Exactly, the point was to create a new, non-POSIX-compliant OS, as POSIX is outdated.

>Linux will always win purely because it has more existing software.

That's similar (not the same) to saying that windows wins because there is so much software. This is a matter of principle and ideals. non-CoC, non-Corporation-controlled and modern is what I want.

> 8ch has it's own formatting. You can see it if you click on [options] up at the top, then "customize formatting".

Thank you for the tip.

> You can either be that sperg, or give up now.

I will gladly sperg up for this, however, I also hope that I can find at least one more sperg to do so with me, because one-man decentralised development does not really work.

I will gladly

>>1000438

>why not use a different kernel instead of an entire OS

The problem here is linux has made itself a monolithic kernel, it's built in most of the driver support needed to run most hardware, this comes in the form of modules that directly target linux, this is both a great blessing and a curse as other sort of systems become a pain to port to.

GNU hurd is by far the closest contender to main running linux there is, simply because there is an on going effort to both port and use a wrap layer for these modules.

I'm unfamilar with BSD but i assume it's more or less the same.

The thing about GNU hurd is that it uses a micro kernel, this way of doing things is quite slow so no one really wants to use hurd.

bsd is... well... bsd.

Personally, a system i'd like to see get more support would be plan 9 (or 9front) It's from the same people who orignally made unix so it's pretty fair system wise, sadly it's cursed with suckless faggots.

>>1000472

>The thing about GNU hurd is that it uses a micro kernel, this way of doing things is quite slow so no one really wants to use hurd.

You can still have a monolithic kernel consisting of many modules that are chosen at compile time. If everything is designed to be as modular as possible, that makes the code easy to maintain and replace. Since one does not necessarily need to replace kernel modules at run-time, one can have the many modules statically linked. However, the architecture of the system should make replacing modules (at compile time) easy, without having to recompile the whole kernel.

> plan 9

I will have a look at it.

I also think that a capability-based approach to permission management is promising, instead of just sudo/non-sudo, there should be clearly defined capabilities to lock/unlock. If every program needs to request permission for potentially harmful capabilities, then the user is protected much better against malicious software.

>>1000391

>That would be the easy way, but I think we can do better than that.

WTF are your goals here. Sounds like a boring ass research project.

>>1000480

Please read the thread before posting. thank you.

>>1000477

I just had an idea: I think we could have the object files for every kernel module as part of the system, so that when a module is exchanged, the kernel is recreated by linking the object files with a new module, and replacing the old kernel library with the fresh one. However, I think that such a replacement would be non-trivial to do without rebooting the system. I guess we would need to have every module implement event handlers for the case where a module is removed / added / exchanged.

>>1000378 (OP)

Remember the thread where Anon posted a bootable 'hello world'? Remember how far that thread went?

>>1000485

I am sorry, but I am new to this site.

Also, this is not a "my first kernel"-level project, and obviously requires commitment.

This is a serious undertaking, even though I guess you will probably ridicule / dismiss me based on the fact that I am new to this site.

>>1000486

No, I'm going to ridicule and dismiss you based on the fact that you vastly over-estimate /tech/'s skill and motivation.

>>1000487

Fair enough. I did not expect /tech/ to be swarming with people begging me to participate in the project. However, I will start the project regardless, and I guess that somewhere along the way, someone will join eventually.

>>1000488

Keep us updated man. I'm sure if you can present a mostly usable project with a link to your gitlab you'll get at least a few contributors.

>>1000488

>I will start the project

I'll be waiting, I'll be impressed if you actually do something.

>>1000488

Rust? I have >3.5 years of Rust experience.

>>1000477

>I also think that a capability-based approach to permission management is promising, instead of just sudo/non-sudo, there should be clearly defined capabilities to lock/unlock. If every program needs to request permission for potentially harmful capabilities, then the user is protected much better against malicious software.

No. This problem is already well solved using group permissions (cf the audio, video, usb, etc... groups), it just needs to be extended to stuff that currently need capabilities; which means more stuff under /dev.

The main thing to do is solve the lack of interchange format for UNIX tools.

1) Tabular data: choose at two characters for FS and RS (hint: ASCII RS and US are already here for that purpose) and forbid them in filenames. A more reasonable approach would be FS=\t and RS=\n. Now, all tools must follows the RS and RS env variables and some --rs and --fs options to read and write their stuff.

2) Long options: they're needed so we can have consistent option names without single letter conflicts. In fact, ban short options; alias are here for shortening your command lines.

3) Simple interchange image/video/audio format: netpbm, y4m (better idea?), wav is a clusterfuck of extensions so I don't know (create your own simple PCM format without tags nor compression).

4) Unfuck Perl: reminder that it was supposed to be a more complete AWK+sed+sh, and nothing more (this is already a lot; I suggest you remove the sh part).

5) Unfuck sh: doing 1) will make the work almost non existent; stuff like associative arrays (thus no need to IFS split variables as a hack to emulate arrays; see zsh) and maybe threads (having to use FIFOs to communicate between shells and subshells is painful) would be good. Make it typed, too (just keep the types simple: int, float, string, array should be enough). Don't do an horror like rc, sh has a good syntax.

6) Unfuck C, of course, but keep it simple, so writing a compiler doesn't become too complex.

7) Unfuck signals; no idea how to do that, but there's something to do.

8) Steal the good shit from plan9 (maybe even use plan9 as a base) like bind, 9p or the POSIX compat layer.

9) Fix UTF-8 by having 1 codepoint == 1 grapheme, 4 bytes should be enough for this shit.

10) Do something about terminfo lacking combo keys like ctrl+arrow.

That's already plenty.

>>1000502

Congrats on replacing unix' flaws with new flaws.

>>1000493

>>1000497

I will not disappoint you. Although I am doing this for myself.

>>1000499

>Rust?

I was actually thinking about C or C++ without the advanced features that fuck everything up. I personally think that Rust is a meme language, but if you can convince me, then why not?

I think it is important to chose the language such that modules can be written in multiple languages and still work together. So it would have to be something that is C-compatible (I think Rust should be C-compatible though).

But before programming, we need to set some major design goals. Are you experienced / knowledgeable / skilled in OS design?

>>1000502

Almost everything you recommended is not part of the OS's tasks, except the thing about stealing from plan 9, which (after briefly looking into it) has questionable design choices.

>>1000511

>Rust

it has a CoC brah.

>>1000511

>But before programming, we need to set some major design goals. Are you experienced / knowledgeable / skilled in OS design?

Do you want concurrency? If yes, what kind of? Processes or something else? If processes, what kind of IPC do you want? Multi-user? Special hardware requirements like MMU?

>>1000512

>it has a CoC brah.

so what

just ignore

>>1000514

>Do you want concurrency? If yes, what kind of? Processes or something else?

I think concurrency is important, but I also think that one should have strong control over it (i.e., not have 2 threads on the same core). That said, I am in favour of processes, threads, and userland threads. With "or something else?", I assume you were referring to processes vs threads?

> If processes, what kind of IPC do you want?

I am not sure, I think that shared memory would be great for efficiency, but I would probably implement a basic message passing API as well as a shared memory API, since shared memory is more tricky to use.

> Multi-user?

Not sure about that, intuitively I'd say not needed.

> Special hardware requirements like MMU?

It makes it much more easier to implement concurrent processes.

>>1000526

in the OP:

># Modern design

>A modern, proper operating system should think into the future and dare to prioritise making bold design decisions over compatibility with existing operating systems and software libraries. Although compatibility is great to immediately have, if it means adopting bad design choices from other operating systems, then there will be detriments in the long term.

So not just forking some shit.

>>1000378 (OP)

>many seem to fear that this is the downfall of the Linux kernel,

Nope, not that many. A few fringe elements on imageboards, and people like MikeeUSA. The vast majority of significant contributors to, and users of, the Linux kernel are utterly unconcerned by the CoC. Or if they care, they're not making it known, and they certainly don't care enough to build a new OS from scratch. I'm against the CoC in any form, especially the Contributor Covenant, but you're mischaracterizing the situation.

>think into the future

>dare

>bold

Meaningless marketing drivel. Are you sure you don't just want to go work for Apple? They love that kind of talk there.

>>1000379

>We need to organise in some way to achieve anything with the project.

No shit.

>prevent things like CoCs or corporate/government infiltration

A project is either insignificant enough not to draw the attention of glowdarks, or significant enough to draw the attention of glowdarks. If the former, infiltration is not a concern. If the latter, you can't stop it. Good luck finding people who can not only program an OS but have the tradecraft to thwart glowdarks.

>All code written should be licensed as free software,

OK.

>preferably GPL3,

Pig disgusting.

>The OS should be architecture-aware, but provide a well-chosen amount of abstraction.

wut

>Contributors should use aliases, not only to prevent attention whoring,

Attention whoring is the name of the game in open source/free software. Reputational benefits are one of the few motivations that people have for contributing to this kind of software. Now you've narrowed your pool of potential developers further: OS developers with impeccable tradecraft who want absolutely no credit for their contributions.

>but also to protect against surveillance

If a well-resourced intelligence agency wants to know who the contributors to your project are, they will almost certainly be able to find out.

>I propose the organisation into feature forks, where a feature fork is a fork from an early stage of the project without any other features. To get the whole project code in one place, multiple feature forks can be merged.

Software development as Rube Goldberg machine. What a clusterfuck.

>To prevent centralisation of the codebase into a single repository (see Linux) etc.

You're confusing a social problem for a technological problem, and proposing a technological solution to it. The fact that Linux is in a "monolithic repository" is irrelevant. Under your scheme, if there are 4 OS devs who each maintain part of the OS, the minute that 2 devs disagree with the other 2 about the direction that one of the components should take, you have a fork on your hands. The minute that 3 devs disagree with the remaining dev about his chunk of the OS being official, the remaining dev's repo is just a few unofficial OS features: the 3 will take the last version of the remaining dev's code, assign it to someone else, and christen it the official version. The issue isn't one of centralized repository infrastructure, but centralized consensus. You're not going to solve that by splitting up the OS into "feature forks."

Come back with a few thousand lines of working code, and a plan that's less vague than "a bold, fresh vision for the future."

>>1000521

Sounds somewhat Unix-inspired so far. What about files? Or any other kind of shared namespaces of IPC objects. May I suggest a system where processes can create their own namespaces and pass them down to child processes?

>>1000511

>Almost everything you recommended is not part of the OS's tasks

He isn't giving recommendations for the kernel, but the OS consists of every program that comes with the system, and all the ways they can interoperate. An OS consists of a text editor, a shell, a terminal, a file system, a file manager, a web browser, and any other programs that will be useful to most users. The implication is that every single argument that has ever been had on /tech/, about the best editor, browser, language, font, etc, are all captured in a single OS. You therefore cannot reject any suggestion as "not part of the OS's tasks", because everything is part of the OS's tasks.

>>1000528

These are good goals, but there needs to be a middle ground. Forking for compatibility ties you to existing paradigms. But you can still fork to get the old code base. Linux has drivers for hundreds of different peripherals. You could fork linux, rip out any syscalls you don't like, but keep the old drivers.

You cannot build a clean, modern operating system with clean, modern hardware. The reality is that for now we are stuck with 1980s CPUs like x86 and POWER. RISC-V is new, but it still uses the old ring-style protection. Mill seems like an interesting architecture, but it will take many, many years before they will have hardware for sale. Targeting multiple architectures is code word for targeting old architectures. That implies creating an OS that is not modern. If you really want to build a new OS, good luck, but that's like expecting a democratic solution to our current demographic problems. It's just not going to happen.

If you want to make computing great again, start with something more simple. Sadly, most of the big problems we are dealing seem to be social problems rather than technological problems.

>>1000531

I think files should only be used for what they are supposed to be. I think that there should be files and streams, eventhough they are used similarly.

>IPC namespaces

I think that goes well with shared memory, and the additional layer of organisation should be beneficial for easier understanding.

>>1000532

Well, it will obviously be worth it to reuse parts of linux or use them as a reference.

>>1000511

>But before programming, we need to set some major design goals. Are you experienced / knowledgeable / skilled in OS design?

Lol no. Nobody on /tech/ has any experience beyond wageslaving.

There is a long blog series about Midori, a research OS project from Microsoft: http://joeduffyblog.com/2015/11/03/blogging-about-midori/

It has capability-based security.

>I think Rust should be C-compatible though

Of course it is. https://doc.rust-lang.org/book/first-edition/ffi.html

The best way to replace C with Rust is by sneaking Rust code into C projects. librsvg has already generated butthurt.

My suggestion would be to utilize seL4 as the kernel.

The old way that unix manages things is using the idiom "everything is a file". This clearly doesn't work in the modern age, so it should be replaced: everything is a web server. When you want to edit a text file, you wouldn't execute the file containing your text editor, passing the file containing your text. Instead you would visit the website of your text editor, and give it the url of your text file to edit. Rather than complex and unnecessary windowing system, you would have a simple web browser with a number of tabs. Rather than having to argue endlessly about programming languages and graphics toolkits, ui would be coded with html+css+javascript. Rather than having hundreds of different systems for ipc (signals, pipes, fifos, sockets, etc), communication between servers would be done with good old fashioned get and post requests. The shell would be superseded by the search engine.

Some people might be butthurt that the familiar unix idioms will be dead as dodos. What you have to realize is that they're already dying; most applications are already written as I've described. It's time to finish the job, and move on to the future.

>>1000542

I approve. The web server should be Hyper. It is written in Rust so it can fearlessly utilize concurrency, it is memory safe, and it is blazingly fast. For the web browser the obvious choice is Firefox. But maybe we should use Servo until WebRender is fully integrated into Firefox.

>>1000538

What I meant was that any kind of file is a means of communication between processes. Just like signals, network interfaces, or just process IDs.

Just passing on shared memory pages and letting processes decide what to do with it could work for most applications, but you won't be able to isolate the PID namespace.

>>1000542

The web is stateless, which can be a PITA. Also you may be describing Sun RPC in new clothes. Look it up, it's cancer.

>>1000528

>yes its a research project

Got it. Good luck!

waste of time, openbsd already exists

>>1000550

There is currently a thread about OpenBSD. Looks horrible.

>>1000543

There have also been plenty of kernels written in rust, so we can take our pick:

https://github.com/search?q=kernel%20rust&type=Everything&repo=&langOverride=&start_value=1

>>1000546

>the web is stateless

this is what cookies are for, storing state on the client. We also have localstorage and indexeddb.

>Also you may be describing Sun RPC in new clothes. Look it up, it's cancer.

I have found this:

>https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call

but it doesn't list criticism. It sounds pretty standard as far as RPC goes. HTTP as RPC isn't my proposal though - it is used across the industry. Look up REST protocol for discussion of one of the common ways it's implemented.

>>1000488

So what do you think about this shithole so far

>>1000554

Full of LARPers tbh

>>1000439

Make modules or interfaces have a "role". This is what they do, regardless of how they do it. Interfaces which have a specific role have to comply with a "tier 0" API, which is the bare minimum a module has to do to be considered something part of that role. Everything else is a "diversion" of the API. If it is properly documented and it is sound, it can be included in the "tier 1" API, which basically means "you should support this unless you are looking to make your program an embedded systems exclusive". Anything else is part of the many "tier 2" API, officially documented, but not part of the standard.

Obviously, this should be transparent to application developers. Let all this be handled by the equivalent of the lang's stdli,, another abstraction layer upon which stdlib can be built, or whatever.

>>1000552

Sure you can store stuff in cookies and localstorage, but the server won't remember you.

Especially REST is a bad example. It is used to transfer state (hence the name), but keeping track of it is entirely done on the client side. REST calls are supposed to be idempotent. REST is made for CRUD. This means you can't use REST to start a server-side process that may have side effects on other data on the server. No such thing as "run function x() and give me the result".

RPC may be better suited for calling procedures, but as the very concept of http is that every call is isolated in itself, I'm wondering why you'd bother with http anyway.

>>1000560

>the very concept of http is that every call is isolated in itself

Is this what you think HTTP is? You may be confused. The website your shitposting on is using HTTP, and yet I can see the posts you make, and you can see mine. Generally the architecture is this: the client asks the server for a token. The server complies. The client then makes future requests with the token. The server then modifies the state associated with the token.

>REST calls are supposed to be idempotent

POST requests don't have to be idempotent.

>>1000546

I would actually like to decouple files from pipes etc. Why would a pipe be accessible over the file system? IMO, the file system should only concern itself with storing and accessing files. Although a pipe can easily be implemented to be accessible from the file interface, I think that this is a dirty hack and that if someone wants to read a file, they should only be able to open actual files with their command. The same goes for devices, they are not files and should not act as such.

But using the namespace approach for pipes and files etc seems nice, even though I misunderstood it at first.

>>1000554

I come from 4chan, and I think that /tech/ is better than 4chan's /g/, the community seems way more serious about technology. This is also why I decided to post here and not somewhere else.

Of course, like on every image board, there are anons like >>1000556 but I think it's at a very tolerable level.

>>1000557

That is a very nice idea, I like it. The standard lib would then have tier 0 and 1 API support, but tier 1 functions have to be checked for availability before calling. Tier 2 functions have to be imported, as they can be too diverse to standardise.

Anon I like your idea, but it will be a very very very difficult thing. Besides we could be experienced in C programming, this is totally a whole new level.

Therefore, I suggest forking an old version of Linux, adapt it to the new design and then proceed.

As a suggestion, consider looking at plan 9 design.

>>1000571

It's not like I have any other missions in life, and I have no GF, so no responsibilities to other people (except work lol).

So I don't mind if it is difficult.

>Besides we could be experienced in C programming, this is totally a whole new level.

What do you mean to say with this?

You mean because of the anon that proposed using Rust?

I think as long as every single module has a C-style API, it does not matter what a module is written in.

>Therefore, I suggest forking an old version of Linux, adapt it to the new design and then proceed.

I will try to take as much as reasonably possible without interfering with my design goals. Especially the module specification thing that >>1000557 proposed will probably conflict with some of the linux code base, making parts of it unusable.

> As a suggestion, consider looking at plan 9 design.

I read through the Wikipedia article on it, but in the next few days, I will look deeper into multiple platform designs, and of course also into POSIX to determine usable parts.

>>1000570

>there are anons like >>1000556

I was only stating the truth. /tech/ if full of LARPers. Prove me wrong by actually delivering on your OS project.

Protip: you won't

>>1000572

>What do you mean to say with this?

I meant that difficult may not be enough to describe this.

Main concern is, imho, that bad choices could show to a very late stage of development, and real OS can only be tested with full development.

But I don't want to disapprove your idea, it could be a great thing. Just expressing my thoughts.

>>1000570

>Why would a pipe be accessible over the file system? IMO, the file system should only concern itself with storing and accessing files.

Often a program uses files in place of pipes. I write to a file, and you read from it later. One version of this I've seen are PID files: A daemon writes it's pid to a file when it starts, you can read from it later to know which pid to signal. You also have named pipes, which behave exactly like pipes, but are given a location on the filesystem. The neat thing about these is that the program doesn't need to know it is accessing a pipe. Consider this code for locking the screen:

mkfifo $IMAGE
ffmpeg ${IMG_OPTS} $IMAGE &> /dev/null &
i3lock ${LOCK_OPTS}  -i $IMAGE -n

This is forked from code you can see here:

https://github.com/Ema0/i3lock-fancy/blob/master/lock

Note how the code required no change in order to turn $IMAGE into a fifo. ffmpeg and i3lock don't know and don't care that they're operating on a pipe not an real file.

In general I think it should be true that a program should not concern itself with how a file is being stored. If it is on one hard drive or another, or on some remote server, or in memory, or being fed to it from another process, is not it's concern.

With that said, the modern approach, used by most linux apps nowadays, is to use urls and not file paths. This allows you to more easily treat remote and local resources the same, without having to mount a FUSE for every server you want to access. In order to make this work, you would need to have a common interface for every protocol, so that you can add new protocols without having to update every app to support it.

>>1000542

so your idea is basically replace UNIX pipes with URLs and packets if i read it correctly (t. brainlet). it sounds interesting actually, and would provide a decentralized IPC solution.

we could access devices like that (although this might be too UNIX for your taste):

sysping --data=0x1 syscall://dev.sd.0 or

sys://dev/sd/0

sysping: sends bytes using system ipc packets??

and the UI would be a JS/HTML interpreter, an efficient, lightweight one (read: NOT electron) and the core set of UI libs would be a JS framework, perhaps we could add C binding headers that let us send draw calls to the JS UI manager and HTML/CSS data, so we could get rid of GnomeTK+ and Qbloat. if implemented correctly would potentially be something like GTK, Qt and Electron combined and done right without the 100MB of RAM usage.

>>1000592

Redox already does the URL part.

>>1000387

And that right there is why you will fail.

How crazy would it be to implement the OSI model like it was meant to be done at an OS (userland, of course) level? I would actually fucking love to see my programs all using the same XML parser, the same encryption library, etc, all "transparent" to the developer, so the user can always have a final say on how to route/pipe a given request.

>>1000587

I know that the design choice "everything is a file" is handy in this case, it is very handy in many cases, but it is not clean.

>>1000598

Thanks, I guess this will be helpful.

>>1000551

You can install any wm/de you want.

>>1000622

A native widget system presupposes that most code will be designed specifically for your system. In fact, you expect most code to be written generically for any system. So your native widget system will be primarily used through a toolkit. Once you realize this, it becomes obvious that you should just implement the toolkit directly. Whatever toolkit you choose will probably be much more mature, and so have support for a variety of widgets, themes, language support, etc.

>>1000433

Lisp machines went even further than this. There is no kernel mode and all code can be edited and replaced at runtime.

>>1000455

>Linux will always win purely because it has more existing software.

If you want to win, you make something better. "Worse is better" sucks.

>>1000502

>4-6) Unfuck shitty UNIX languages

There's more than UNIX out there.

>7) Unfuck signals; no idea how to do that, but there's something to do.

Copy how Multics does it.

https://multicians.org/exec-env.html

>8) Steal the good shit from plan9 (maybe even use plan9 as a base) like bind, 9p or the POSIX compat layer.

Plan 9 has all the same problems.

>>1000526

>You could fork that shit and reap the benefits of well-worn code.

UNIX code is well-worn in the sense that it's full of holes.

>>1000535

>RISC-V is new, but it still uses the old ring-style protection.

RISC-V does not use rings. Multics rings allow different privileges to be associated with different procedures running in a process, which neither UNIX nor Windows do. Most UNIX "innovations" are actually undoing real solutions to problems, like claiming that getting rid of toilets and shitting your pants is a solution to clogged toilets.

https://multicians.org/protection.html

>Thus, a call by a user procedure to a protected subsystem (including the the supervisor) is identical to a call to a companion user procedure.

>The characterization of rings as a restricted implementation of domains is the result of hindsight. When developed, rings were viewed as a natural generalization of the supervisor/user modes that provided protection in many computers.

>>1000542

>The old way that unix manages things is using the idiom "everything is a file".

That's actually marketing bullshit created as a reaction to "everything as an object" in languages like Smalltalk and Common Lisp. In these languages, integers, lists, arrays, strings, structures, classes, functions, packages, and all other data are objects. In UNIX, none of those things are files.

Date: Tue, 19 Nov 91 13:53:22 EST
Subject: Once Again, Weenix Unies Reinvent History


   Date: Tue, 19 Nov 91 08:27:49 EST
   From: DH

   Yesterday Rob Pike from Bell Labs gave a talk on the
   latest and greatest successor to unix, called Plan 9.
   Basically he described ITS's mechanism for using file
   channels to control resources as if it were the greatest
   new idea since the wheel.

Amazing, wasn't it?  They've even reinvented the JOB device.
In another couple of years I expect they will discover the
need for PCLSRing (there were already hints of this in his
talk yesterday).

I suppose we could try explaining this to them now, but
they'll only look at us cross-eyed and sputter something
about how complex and inelegant that would be.  And then
we'd really lose it when they come back and tell us how they
invented this really simple and elegant new thing...

>thread about making a non-coc os

>people start talking about fucking rust (has a coc)

>people start talking about writing the UI in pajeetscript

/tech/ == /g/

8chode == 4cucks

>>1000759

learn to identify shitposts.

> inb4 you fell for it

>>1000652

Still waiting on you to begin working on a modern successor to LispOS.

>>1000760

no that html ui dude is a retard, he also wants to replace pipes with packets

>>1000771

He's not a retard, he's a shitposter.

>>1000652

> Multics

It's really tiring to read the papers, but I'll try to work my way through them.

> RISC-V

I think I will add RISC-V features into the OS, which will have to be emulated on other architectures. The reason for that is that RISC-V is more modern, and on top promotes freedom.

>>1000652

>RISC-V does not use rings.

Yes it does, except they're calling them "privilege levels". Chapter 1.3, https://github.com/riscv/riscv-isa-manual/releases/download/draft-20181121-c743d2f/riscv-privileged.pdf

>>1000779

>I think I will add RISC-V features

Such as?

>>1000780

As far as I understand, Multics rings are a RISC-V thing, and they work different from x86 rings. They offer more fine-grained control.

>>1000604

It's stronger than just handy. It is the necessary level of abstraction. It is not the responsibility of the tool to keep track of where my files are coming from, and change their behaviour to match. I don't know how you use the word "unclean", but a system that forces a separation between files on disk and files in memory creates unnecessary work for all parties to no visible advantage, which I see as a very unclean thing to do.

>>1000771

It always pissed me off that send/recv aren't just write/read. I suppose one difference is that a socket is two sided, whereas file descriptors are normally unidirectional. But this distinction doesn't seem sufficient to justify two separate io apis.

>>1000773

Thanks for defending me anon :)

>>1000803

> It's stronger than just handy. It is the necessary level of abstraction. It is not the responsibility of the tool to keep track of where my files are coming from, and change their behaviour to match. I don't know how you use the word "unclean", but a system that forces a separation between files on disk and files in memory creates unnecessary work for all parties to no visible advantage, which I see as a very unclean thing to do.

> It always pissed me off that send/recv aren't just write/read. I suppose one difference is that a socket is two sided, whereas file descriptors are normally unidirectional. But this distinction doesn't seem sufficient to justify two separate IO APIs.

I think that only files should be treated as such: You can seek in a file, tell its size, append, delete, overwrite. You can do no such thing with a socket or pipe. What would be more sensible is to provide a stream abstraction, where you can use sockets, files, microphones, etc., with an API that allows to read/write bytes (even then, there needs to be a distinction between read-only, read-write, and write-only streams). If you want to meme it the UNIX way, then use the stream API for everything. But if you want to have powerful file manipulation primitives (mainly seek, tell), or socket primitives (shutdown, etc.), then you need to access an API that is designed only for files (or sockets, respectively).

I am a big fan of type-safety, and *everything is a file* just doesn't fit right with me.

Also, why would you use filesystem locations to locate a socket or keyboard? It is a fucking filesystem, there to organise data on your permanent storage into named FILES and DIRECTORIES.

Also, in the UNIX file api, not every file operation can be applied to every file, which is why I say it's not clean. Rather than that, I will make a FILE,SOCKET,KEYBOARD,PIPE < IN/OUT-STREAMABLE hierarchy. If something fits into the FILE concept, then all file operations can be applied to it. If something is a SOCKET, then all socket operations can be applied to it. And so on. The UNIX equivalent of a file would then be IN/OUT-STREAMABLE, which applies to almost everything. I would also make a distinction between filesystem locations and pipe names, device names, etc. You could, for example, create a streamable handle to a file via file(location) or file://location, and devices via dev://name.

>>1000817

>>1000803

> a system that forces a separation between files on disk and files in memory creates unnecessary work for all parties to no visible advantage, which I see as a very unclean thing to do.

I never did say, or intend to say, that files in RAM should be treated differently from files on a HDD or SSD or other storage medium. I did say that the API for files should only be applicable to files.

>>1000817

A direct consequence of this is that URLs will be the default way to pass resources, which will also make it easier to pass remote resources, as the programmer would not try to open everything with the file API, but with the streamable API, which would then detect remote URLs and other things, and handle them accordingly to the specified protocol.

Right now I at the stage where I have the following resource types:

Files, devices, pipes, connections, locks, conditions, barriers, events, futures, promises.

The following abstractions exist:

Stream = {file, device, pipe, connection}

Awaitable = {condition, barrier, event, future}

I have taken many synchronisation primitives, as I am convinced that they should be supported for simpler cooperation amongst processes. I.e., if you want to synchronise execution, and need a barrier, then on UNIX, you would have to do some strange IPC, and even simulate the barrier in one master process.

Everything having a web address is what Alan Kay said a modern Smalltalk machine should have. Every object would have a network address. Is OP taking his ideas and merging them with ((( rust )))? Don't use rust either unless you want AIDS.

>>1000836

What? I said URL, which stands for Uniform Resource Locator. I was not talking about web addresses (which often are expressed in terms of URLs).

>>1000840

>>1000836

To be precise, I think that resources such as locks, if owned by processes, should be located in that process (i.e., barrier://<pid>/<id>). Only file:// and ftp etc. URLs would actually correspond to a location in the network or in a file system.

>>1000840

>web address

I meant to type network address.

>>1000848

Well, in theory, one could do that, but only with a well thought-out access control scheme. But as long as one is authenticated, I don't see why it should not be possible to interact with other machines like the local machine.

One could have a default OS interaction port, and resource references across machines would then be something like:

wait condition://machine-name:port/pid/id

it's easy to make an OS faster than any current bloated piece of shit. i've been working on an OS for 10 years which is memory-safe, has a single PL with small amounts of assembly to boostrap, and is slow and secure and has no 3D graphics.

>non-CoC OS

but I doubt anyone who thinks in CoCs can help

>>1000870

>it's easy to make an OS faster than any current bloated piece of shit.

I don't think that speed is everything. I believe that the system should be programmer-friendly, and that you should be able to use it to easily program user-friendly programs.

I don't need it to outcompete in terms of speed or games or whatever, I just want a platform that truly respects freedom, is not subject to corporate interests and tyranny, and allows me to comfortably program it. As programming is evolving, so should the OS.

>>1000780

>Yes it does, except they're calling them "privilege levels".

RISC-V is based on the PDP-11's supervisor/user modes with extra hypervisor and "machine" modes. The 286 and 386 protected modes were inspired by Multics. Instead of a kernel, Multics has code segments that run in certain rings. Running in a ring gives access to other segments in the same or outer rings. In both Multics and x86, each ring has its own stack segment. This goes beyond microkernels and also solves the PCLSRing problem and these other bullshit UNIX problems in a very simple way.

>>1000791

>Multics rings are a RISC-V thing, and they work different from x86 rings.

Multics rings and call gates are exactly like x86 rings and call gates. On x86 and Multics, a single process enters multiple rings depending on the code that is executed. The only reason call gates aren't widely used is because they're not portable to RISCs and other worse hardware.

https://en.wikipedia.org/wiki/Call_gate_(Intel)

>And as most other architectures do not support call gates, their use was rare even before these new instructions as software interrupts/traps were preferred for portability.

>Call gates are more flexible than the SYSENTER/SYSEXIT and SYSCALL/SYSRET instructions since unlike the latter two, call gates allow for changing from an arbitrary privilege level to an arbitrary (albeit higher or equal) privilege level. The fast SYS* instruction only allow control transfers from ring 3 to 0 and vice versa. Upon comparing call gates to interrupts, call gates are significantly faster.

https://en.wikipedia.org/wiki/Global_Descriptor_Table

https://en.wikipedia.org/wiki/Task_state_segment

>>1000817

>But if you want to have powerful file manipulation primitives (mainly seek, tell)

UNIX files suck so much that seek and tell are considered "powerful file manipulation primitives" but most mainframe OSes have keyed and random access files. Files on these OSes are designed for random-access disks, not tape drives. Even "seek" and "rewind" are tape drive bullshit that slow down your computer and clog up your brain preventing you from understanding what your computer can really do. A disk lets you access multiple parts of a file without having to read everything in between and an SSD is even better at this. A consequence of the UNIX way is file formats like XML that are designed to be read one character at a time.

>Also, in the UNIX file api, not every file operation can be applied to every file, which is why I say it's not clean. Rather than that, I will make a FILE,SOCKET,KEYBOARD,PIPE < IN/OUT-STREAMABLE hierarchy. If something fits into the FILE concept, then all file operations can be applied to it. If something is a SOCKET, then all socket operations can be applied to it. And so on.

That's why OOP and inheritance are good. "Everything is an object" also means files are objects, but "everything is a file" means UNIX weenies don't know what "everything" means.

I don't regard it a "real" UNIX, then again I wouldn't buy a
"real" UNIX, 1970s software technology is not something I
would want to buy today.

Getting caught up in the "pure" UNIX war will lead you to
restrict yourself to "pure" SVR4 implementations, in the
mainstream camp *only* SUN have gone for this. That in my
view does not make it much of a "standard".

If a vendor decides to do something about the crass
inadequacies of UNIX we should give them three cheers, not
start a flame war about how the DIRECTORY command *must*
forever and ever be called ls because that is what the great
tin pot Gods who wrote UNIX thought was a nice, clear name
for it.

The most threatening thing I see in computing today is the
"we have found the answer, all heretics will perish"
attitude. I have an awful lot of experience in computing, I
have used six or seven operating systems and I have even
written one. UNIX in my view is an abomination, it has
serious difficulties, these could have been fixed quite
easily, but I now realize nobody ever will.

At the moment I use a VMS box, I do so because I find that I
do not spend my time having to think in the "UNIX" mentality
that centers around kludges. I do not have to tolerate a
help system that begins its insults of the user by being
invoked with "man".


Apollo in my view were the only UNIX vendor to realize that
they had to put work into the basic operating system. They
had ACLs, shared libraries and many other essential features
five years ago.


What I find disgusting about UNIX is that it has *never*
grown any operating system extensions of its own, all the
creative work is derived from VMS, Multics and the
operating systems it killed.

>>1000882

based

>>1000882

>PCLSRing (also known as Program Counter Lusering[1][a]) is the term used in the ITS operating system for a consistency principle in the way one process accesses the state of another process.[2]

Huh

>UNIX files suck so much that seek and tell are considered "powerful file manipulation primitives" but most mainframe OSes have keyed and random access files

>reading is hard

when you get a file over the network, you can't arbitrarily seek on it. So seek and tell are powerful. Modern unices have access to mmaps and whatnot, when those things are useful.

>A consequence of the UNIX way is file formats like XML that are designed to be read one character at a time.

If XML is too slow, choose a different format. A consequence of the unix way is that you can choose the file format that suits the problem.

>inheritance is good

your spouting bullshit now aren't you? one of the hard won lessons of the decades long OOP experiment is that inheritance is one of the shittiest ways to compose objects.

>>1000890

<inheritance is good

>your spouting bullshit now aren't you? one of the hard won lessons of the decades long OOP experiment is that inheritance is one of the shittiest ways to compose objects.

What the hell? Nobody said anything about composing any objects via inheritance. This is about basic inheritance of concepts. A dog IS AN animal, this kind of inheritance. A file IS A streamable object. That has nothing to do with how I actually implement files, it merely states that on an abstract level, something is a generalisation of something else.

>>1000893

>This is about basic inheritance of concepts. A dog IS AN animal, this kind of inheritance.

That's dog shit too, university fellator.

>>1000938

Wow good argument.

>>1001229

first off, >>1000979 is some anon, not me (OP here).

> The inheritance you describe is simply an abstraction over that concept.

That is exactly what inheritance in the scientific sense means. I am not talking about the feature called "inheritance" in C++/Java. Those make additional assumptions to make composing objects easier. I am also not talking about making everything an object. The thing I intend to do is to create an API that correctly represents abstractions and concept hierarchies, which is actually easier to understand for newcomers than to have axioms like "everything is a file, even if it is actually something else".

>>1001229

> without understanding WHY you are applying inheretence outside of the OOP teaching material

I think you do not understand that inheritance extends outside of OOP, and designing an OS API is still programming, so it is technically still inside the field of programming, and therefore OOP techniques apply.

>>1000890

>Huh

In Multics, each process has a separate stack for each ring. Multics uses this to its advantage to handle faults when running in ring 0. Faults occurring in other rings are simpler and you can retry or continue the operation or GOTO somewhere else.

>Crawlout occurs when ring 0 encounters a fault on the call side. The supervisor attempts to clean up, by executing any cleanup ON-units, and then:

>checks if any ring-0 databases or directories are locked, salvages and unlocks them

>abandons the inner ring stack

>pushes a new frame on the top of the outer ring stack ("caps the stack") and calls the ring's signalling mechanism

>when you get a file over the network, you can't arbitrarily seek on it.

Of course you can. FTP let you download a portion of a file for decades. So does HTTP.

>So seek and tell are powerful.

To a C weenie, finding the length of a string is powerful and takes a lot of cycles.

>If XML is too slow, choose a different format. A consequence of the unix way is that you can choose the file format that suits the problem.

A consequence of the UNIX way is that you have to rewrite millions of lines of code in all different programs and libraries if you want to change a file format.

>one of the hard won lessons of the decades long OOP experiment is that inheritance is one of the shittiest ways to compose objects.

The real lesson is that you should fix things that are broken instead of blaming the whole concept. OOP works but OOP in C++ is broken. The "diamond inheritance problem" is not a problem in other languages with multiple inheritance. It should really be called an "inheritance bug in C++" because that's what it is.

>>1001229

>What you're describing is just Dispatch based on Type. The inheritance you describe is simply an abstraction over that concept.

Inheritance provides additional consistency and guarantees compared to unrelated types. In that example, an ANIMAL has an age, so by saying a DOG is an ANIMAL, you guarantee that a DOG also has an age. Common Lisp also has a static type system in addition to the dynamic typing. Everything in Common Lisp has a type and T is the supertype of all types.

>Because of this, you won't understand the inherent limitations of Java/C++ style OOP design. If you want a better understanding of what Objects bring to the table, go look up Smalltalk and it's Object System since it taught Common Lisp a few tricks.

Common Lisp and Smalltalk are even more class-based than Java and C++ because everything has a class (including classes). What gives Smalltalk and Common Lisp less limitations is the ability to create and redefine classes at runtime and to change classes of objects.

http://www.lispworks.com/documentation/lw70/CLHS/Body/04_c.htm

>Erlang is another logical extension of what Smalltalk brought to the table. You'll notice that Inheritance is missing. Your homework is to find out why.

Erlang is dynamically typed, but organized completely differently from Smalltalk. It's not class-based or method-based.

The talk is mostly based on paper [1] augmented by ideas
from [2].  Because of its C heritage, C++ is both weakly
typed and weakly structured.  Because of the basic design
decisions that were made in its object-oriented extensions,
I claim that C++ is also weakly object-oriented.  I will
discuss several aspects and consequences of what I call the
Fundamental Defect: that objects do not carry inambiguous
type information at run time, in contrast to almost all
other OO languages.  The undisciplined handling of pointers
(as in C) makes the problems worse.  I will also mention
some interesting problems of multiple inheritance, mostly
pertaining to the distinction between "virtual" and
"non-virtual" base classes (superclasses).  Several other
features and their problems will be mentioned, such as:
reference types and argument passing, nested classes,
storage classes and garbage collection, overloading,
assignment and copying, templates (genericity) and
exceptions.

The worst disadvantage of C++ at the moment is political:
accepting C++ as the standard OO language de facto tends to
kill other existing languages, and stifle the development of
a new generation of essentially better OO languages.

Ample time will be left for questions and discussion after
the lecture.  That allows us to look at some details that
really interest the audience.  Also, many of my opinions are
controversial, and I do not expect all listeners to accept
them quietly.

>>1001264

based

>>1001264

>>when you get a file over the network, you can't arbitrarily seek on it.

>Of course you can. FTP let you download a

portion of a file for decades. So does HTTP.

HTTP only when the server supports it. In general, it requires protocol support, which is not given. The salient point is that you can sometimes seek, and you sometimes can't.

>A consequence of the UNIX way is that you have to rewrite millions of lines of code in all different programs and libraries if you want to change a file format.

This is what libraries and dynamic linking is for. The real consequence is that a serialization lib doesn't have to be a centrally agreed upon standard like file systems are, and can instead be an organically grown de facto standard.

Ultimately if you can't realistically examine the entirety of the code within a reasonable time-frame then there's room for error and risks. Everything else stems from this one fact.

For an example the recreation of the original vi is "approximately 160 kBytes on i386", making it realistic and reasonable for someone to examine the code line-by-line.

>>1001280

This but unironically

>wahhh non-CoC

>let's make it commie GPL

nigger brained retard

>>1001492

>everything that is not according to my values must be communism, in fact, all the evil in this world is communist.

Question your government propaganda from time to time please.

>>1000378 (OP)

You guys are too ambitious. You need to abandon the entire concept of the "general purpose operating system" and go for the embedded/console model. Pick your thing and target just that, and later on expand it and allow additional modules. Fire up a basic HTTP browser on an ARM CPU and connect to the internet based on 100% homegrown open source code. Slip in anime videos later.

>>1001492

>too ambitious.

I will of course leave out features in the beginning, it is more important to get a console running than to have audio drivers.

>basic HTTP server

That's what you do with your OS, not what the OS itself does.

>>1001531

> >>1001492

Oops, I meant to put >>1001526

>>1001531

>That's what you do with your OS, not what the OS itself does

No, that's what you do with a general purpose OS that's supposed to do "everything". That's the model that's wrong.

CoC: Linux, FreeBSD

Non-CoC: OpenBSD, NetBSD, DragonFly BSD

Am I right?

>>1001534 Is SmartOS also CoC OS?

>>1001533

Since when were you under the impression that I want to bloat my OS?

>>1001508

>implying leftist socialist neo-commie government propaganda is anticommunist

lmao

>>1001542

Well, question it anyway.

>A modern, proper operating system should think into the future and dare to prioritise making bold design decisions over compatibility with existing operating systems and software libraries.

That vague phrasing sounds like it came from the ivory tower, and the fact that you're going to /tech/ to get any serious work done shows you are absolutely out-of-touch with this image board and what it is capable of.

People come here to shitpost and feed their ego. Drawfags might make you a mascot for your new OS, but outside of that you're going to be doing all the work. I strongly suspect anyone here who's capable of helping you will wait to see whether your idealistic zeal will endure over even a month of having to do work for free.

Why don't you come back once you have more than vague notions of what you do or don't want to magically happen?

>>1001556

>I strongly suspect anyone here who's capable of helping you will wait to see whether your idealistic zeal will endure over even a month of having to do work for free.

This.

>>1001556

>ivory tower

Are you mad at my idealism?

>the fact that you're going to /tech/ to get any serious work done shows you are absolutely out-of-touch with this image board and what it is capable of.

I frequent this thread, as from time to time, useful suggestions are given. I posted on this image board, because I feel comfortable here. Also, my inspiration for this project came from browsing here, so I thought, I should keep the project here.

>Drawfags might make you a mascot for your new OS

I will need to think of a non-niggerlicious name first. When I've done that, I will also upload my work. Until then, I will be working on my local machine only.

>you're going to be doing all the work

As stated previously in this thread, I am going to do this completely on my own, if nobody is willing to contribute. After all, since I want to use this operating system, and since it does not exist yet, it is entirely my responsibility to create it myself. Of course, together with others, it is easier to recognise bad design choices early.

>work for free

Since you pity me so much, just for you, I will put up a crypto donation address in the repo.

>Why don't you come back once you have more than vague notions of what you do or don't want to magically happen?

I am currently writing a rather abstract specification, containing any high-level design choices I come up with. It grows more specific by the day, but it is a slow and tedious process, as I have to always ask myself: "Is this really a good decision? Isn't there a better way to do this?". As stated in the OP, I do not just want to create an OS of my own, but a quality OS which is cleanly designed and modern.

>>1001573

>Are you mad at my idealism?

Less mad, more annoyed.

>>1000890

Technically, you can. At least if the protocol supports it, which would be the case if it is designed from the ground up, which should be the case. Even HTTP does support it, so there is that.

>>1000438

>Remember LibreBoot?

I don't. What happened to Libreboot?

Everything looks like a file, but it actually is just a generic value. What tyoe of value it is is completely transparent to the user or developer at any time, but it needn't be known for it to be used. For example, let's say we go balls to the wall with the runtime transparency, to the point all programs in our OS appear in our own "/run", and can receive signals that way ideally, you would actually have a better way of communicating something to a program rather than by knowing its PID, beforehand, but let's leave that for later. We are running, say, a webserver, where we can and want to turn on the cacheing of pages right now with a command.

/run/1009/private/settings/cache < true

This looks pretty unixy, but the way it works under the hood is not exactly that way.

First, you are not accessing the filesystem at any given moment, as you are accessing the "system graph", which is a virtual tree-like structure which can offer representations of the actual file system, but doesn't have to. This more or less is just a rewording, since modern unixes offer a filesystem as virtual as they like, but in this case we are being honest about what's going on under the hood.

/, as usual, is the system graph root, let's call it Monad because I like that word, and because I want to be a special snowflake. All it is is the first node of a the tree which represents our system. It may have some special properties, but generally speaking, it is just a folder. A virtual/volatile folder, which means it is present in your memory (generally speaking, where it is physically located should not be important for anything else but optimization purposes, but the system is very transparent about it) and not in your filesystem. Volatile means this folder will be recreated at some point in the future (ie. on next boot) by the OS or another program, so anything placed on a volatile folder, even non-virtual stuff that may be actually present in disk, will be lost and possibly erased. In order to permanently store something, you have to put it inside an "anchored" folder, which is a folder with an actual representation in the filesystem. The Monad is the only volatile folder that can hold anchored folders.

run/ is yet another virtual volatile folder. It is where all processes are located and exposed for everyone to see. So is private/, which is where the program holds all the stuff the program wants to expose to people with permissions (public would obviously be what it exposes to the world, which, if designed correctly, could even be the website itself, but would usually be just a public API and non sensible read only values). All folders are in this OS are "transient nodes", which means they can contain other nodes inside them, but not values.

We get to the settings folder. While it is accessed just like a folder, it is actually not. The main difference is it is actually an object, or struct, or whatever you want to call it. This means all its contents are defined at its inception, and can't be modified by anyone, not even the superuser. This is, simply put, a table of named values, just like a struct in any statically typed programming language. We go with static typing, no matter the underlying language, because a program wouldn't be able to identify new values nor know what to do if a value was missing, even if they can modify the contents of structs at runtime (for example, because they may actually be hashtables and not structs).

Then, we get to the cache node. It is actually a terminal node, which would be a regular file in most filesystems. It contains a value, and that's it. However, in this case, this is not a file. It is a value, a boolean typed value to be specific, and a virtual/volatile boolean value, to be pedantic. Values can be read to and from a value file, but only whole. Composite values, like strings, are actually special folder-like values with special properties, which could be read from whole if accessed as a terminal value, or accessed in ranges as if it were a folder.

Finally, if the program has declared at some point to the OS (either in the executable, or during runtime) that it wants to be informed of changes to that value, the OS will send a signal to the program informing it from such a thing, so it can operate accordingly.

>>1001951

Thank you for the pdfs, very much appreciated.

>>1002058

very nice post. I especially like the intuitive way of creating interfaces. The next obvious step is to create a shell language that can handle structs and typed values (possibly including an 'Any' type), and then, when accessing a property of a program, a value is then sent to it, possibly as a JSON-like representation. This is very much in line with the idea I had about sensible typing.

I think that using protocols names ("run://1009/…" instead of "/run/1009/…") is even cleaner, as they do not suggest the existence of a system tree. Firstly, I think that explicitly exposing everything as a tree that contains the file system tree confuses users, as it suggests that everything is in the file system. Second, having a protocol instead of a directory makes it more obvious what type of resource one is accessing.

connection://3583/send < "Hello world"

/connection/3583/send < "Hello world"

This is a nice example comparison: The type and the identifier are cleanly separated. I would also consider using a "." notation to access properties, which is more intuitive to programmers, somewhat like this:

run://1009/private.settings.cache = true

I also changed from "<" (which usually means read input from file) to "=", which makes it even more obvious that a value is assigned. Similar to C++ constructors, "a=b" would be equivalent to "a(b)", which has the advantage that functions taking multiple or no arguments can be exposed the same way as getters and setters. If the shell has full nested expression support, then it is easy to write C-like programs in the shell.

run://3583/add_connection("127.0.0.1", 8080)

or, more in line with current shell syntaxes:

run://3583/add_connection "127.0.0.1" 8080

Also note that I removed the "private" part, as anything that's accessible this way is explicitly exposed already.

Now, we have the possibility of exposing virtual programs to the rest of the system, and the "<" syntax would call that virtual program with the contents of a file. The same way, pipes could be used to feed a program output into a virtual program. However, I would very much prefer something like

run://1203/program $(some_program)

or, in C-style:

run://1203/program(some_program())

I am not sure whether C-style calls or shell-style calls are better, the major difference being that shell-style calls are easier to extend with additional arguments.

> ideally, you would actually have a better way of communicating something to a program rather than by knowing its PID, beforehand, but let's leave that for later

I think it can be done similar to connection ports: why not let processes choose some number under which they are accessible, and if it's taken already, then they exit. This needs to be optional though, since anonymous processes need to be possible too. There could also be string names, although they would have to be limited in length.

as "server123" myserver "localhost" 1337

A special "as" command could make naming simpler.

>>1002109

So this would mean, I could access my "server123" task as follows:

run://server123/cache("htdocs")

This will effectively make coroutine-like programming possible, where every program exposes a public interface for interactions, and programs can message / query each other without much effort. Of course, as message passing is not very efficient on most architectures, a shared-memory version of the protocol that runs in user space should be supported as well. Then, if a program wants to create a shared-memory channel to another program, then it only needs to query it via message passing, i.e.

run://some-program/shared_memory(this_pid,memory_size)

This whole interface thing is exactly RPCs, so the protocol should be called rpc://

I refined the idea a little further: I abolished the rpc:// protocol, instead, I added the "->" RPC operator. In the shell language, using the "async" keyword allows a process to be run asynchronously, and the process ID is returned. This means that we can write:

$server = async ./server("localhost", 1337);

$server->cache(htdocs/index.html, "RAM");

RPCs themselves can also be made asynchronous via the "async" keyword, but I am not sure whether to allow an RPC to implement an RPC interface itself. This would make the language and RPCs more powerful, but at the same time, the system becomes more complicated. This way, RPCs could become like objects, with member functions of their own. The object (RPC) is stored in the process that it was produced by. I can imagine a use case: If I RPC a window manager to create a window, I could use the returned handle to control that window, i.e.:

$wm = async ./window-manager();
$window = async $wm->create_window("My first window", 800, 600);
$window->show();

>>1002661

Instead of a variable, a number can be used as well:

1520->show();

Here's the Repository: https://gitlab.com/GXA8qGNp9971/epos

Although there has been a project called "epos" before, it seems that it has died a few years ago already, so I do not feel bad about the name choice.

I'll make the logo

>>1002668

I'm looking forward to it. I was also thinking of having a wizard or hero as mascot…

>>1002666

I'll write a Rust implementation tomorrow.

>>1002666

THE ABSOLUTE MADMAN HE'S ACTUALLY DOING IT

>>1002713

Thanks for the praise. I don't have much free time, so progress is not optimal. But I am dedicated to it, so it will be usable eventually.

>>1002710

I think it's better to spend more time planning before starting to code. The concept is still way too vague. I want to have a quality product.

>>1002666

https://gitlab.com/GXA8qGNp9971/epos/blob/master/spec/Resource.md

>pipes

Instead of pipes, allow programs to output an arbitrary data structure. You can emulate UNIX pipes by just outputting a character stream. Instead of having a program like awk, you have a program which can turn something from one data structure to another.

>>1002749

You could say that ordinary unix pipes can already work on arbitrary data structures.

>>1002751

If the person writing the script has different idea of what the data structure is than the author of the program you can run into problems. This leads to developers not being able to change the output of their application because some script might depend on some weird formatting in the output.

You also run into the problem where you have to convert numbers into text and then back into numbers instead of just passing the numbers.

Data structures which pass multiple streams are going to require you to create some protocol to use over the pipe in signifying which sequence is being added to.

OP here.

>>1002749

>Instead of pipes, allow programs to output an arbitrary data structure. You can emulate UNIX pipes by just outputting a character stream. Instead of having a program like awk, you have a program which can turn something from one data structure to another.

I think pipes are sufficient, what is needed is an OS-wide standard for formatting data structures, which I would probably make in raw form, and not as text, as serialising into readable text has too much overhead, and the next program is going to deserialise it again anyway. I would go for something like a raw JSON format.

What I do not like about UNIX pipes and processes is that they make it impossible to invoke a program like a function. Every program has 1 implicit input pipe and 2 output pipes, which makes it hard to get the actual value returned by a program (its useful output, such as a computation result), since it might be mixed with user input prompts. Even if all user input prompts are written to stderr, that just messes up the error logs.

I am not sure whether just increasing the amount of output pipes a program has solves the problem. There needs to be at least one pipe that only contains the result data, one for prompts, and then probably multiple pipes for different levels of logs, warnings and errors. The problem is that I need to make the pipes easily accessible in the shell. What I could do is use the "async" notation to access a process, and then via the acquired process handle, configure the output pipes, but that's also not very clean, as the configuration of the output pipes should be complete before the program starts executing.

The other problem is that since every program has an implicit input pipe, you cannot just write f(g(x)) to pass g(x)'s output to f. And the notation g(x) | f() is also shitty, since this only works for one argument. If I wanted two pipes for a program, I would have to use g(x) | f(h(x)), to pass g(x), h(x) to f. I am not sure yet whether the issue is purely notational or if the concept of implicit pipes is inherently flawed.

This notational difficulty is also what makes shell scripting different from programming. In proper programming languages, everything a function gets as inputs is written explicitly as parameters, and not as some implicit input that can also explicitly be modified. Maybe I should make the stdin pipe explicit, so all of a program's arguments are automatically pipes (or streams, which is essentially the same). If I then want a program to read user input, I need to explicitly pass the user input stream as a parameter. So, to call sha512sum with user input would be look like this:

sha512sum($IN)

P.S.: I am a little confused right now.

>A path is a zero-terminated byte string

No. This is cancer.

>>1002109

This is great, except the part where you use numbers for trackig processes. Sure, you can use a system call to get the PID. But you're still thinking too UNIXy.

As an example, for settings I would rather use the following :

settings://firefox/cookies.allow_third_party = false

Than swimming through /etc.

I still think using URIs is better than having dedicated system calls, though that couldn't hurt for security.

// This wouldn't work for files, streams URIs, etc

void* get(char* uri);

>>1002867 (cont.)

Actually, why not let processes define URIs directly ?

This way, you can let user-level programs define settings://, irc://, etc. First one to register it gets it. A package manager would be more suitable for settings://. The init system for run://. The filesystem for file://.

You'd need a distinction for the type (file, stream, shared pointer) of URI, so the kernel can reject file open on a non-file uri.

// Using signals for handling here - maybe we shouldn't

int register(char* uri);

>>1002851

You do realise that syscalls have a limited numner of arguments? I don't see any problem with C strings, they even consume less memory than size-tagged strings. And if you need to support 0-bytes, strings are the wrong data type anyway.

>>1002868

That's a nice idea. I think that some protocols need to belong to the kernel though, such as file://. Files are so essential to the system that they are the default resource in the shell (if you omit file://, it's still treated as one). I think those protocols should only be used for resources, and RPCs should be handleld separately, as RPCs are an action, and not a resource.

I think that representing processes via numbers is the easiest way. Singleton processes could register their name globally ($$window-manager?), while non-singleton processes need to be accessed using my "async" construct.

>>1002946

Size tagged is better. Use something like C11 _Generic to have the size field be of variable size (i.e. make a string and a small_string type).

>>1002954

I guess it would be easier to copy/map strings to kernel space if you knew their length beforehand.

>>1002982

I don't see a use case where copying an URI is useful. Files, sure, but not a path.

>>1002946

Yes, I thought about it some more, PIDs make way more sense. If you need to know the program's name, it probably exposed its own uri:// api anyway.

If not, then you're obviously doing hacks and need root to iterate over the processes.

btw, single user or multi user ? I think everybody has their own PC by now, so that could simplify the design.

>>1002946

>I don't see any problem with C strings

Unironically kys yourself, faggot.

>>1002992

>btw, single user or multi user ? I think everybody has their own PC by now, so that could simplify the design.

I did not think about that very much yet. Of course, multiple user accounts for shared machines (think of little kids owning a shared computer, because they are not spoiled) should be supported. However, simultaneous access from multiple users (like on a server) are more complicated. I think it would be good to design the system to allow this. I think there should be an isolation system: Processes can chose (or the invoking shell) whether they want to be accessible to other processes of the same user or all users (or a group). The same goes for processes that expose an uri:// name.

So I would enable it by design, but I wouldn't implement it (at least not as any immediate priority). The development focus will be on getting it to run for single users, while keeping the system design general enough to support more cases.

It would also be interesting to have support for distributed execution on the OS/middleware level.

>>1002992

URI copying is important, as you need to pass it to a system call. If you do not copy it, you need to at least map it into kernel memory. For 0-terminated strings, you need to read the whole string before knowing its bounds. This means that you do not know how much memory to reserve beforehand.

>>1002666

>Numbers are handled like in C.

0 being octal was a mistake.

>Loops and if-statements are syntactically the same as in C.

C doesn't even have a real for loop.

>>1000378 (OP)

>>1002666

If Terry Davis can do it so can you. Quit bitching and start writing.

If you want to brainstorm and have any misgivings about ideas you need to substantiate your claim, and contribute to the discussion otherwise just go fucking die.

Godspeed.

>>1003070

Using a system call doesn't require the string to be copied. Since system calls are blocking, there's no point in copying the char*. This isn't javascript.

>>1001573

>Are you mad at my idealism?

https://www.youtube.com/watch?v=WWVMXLSS1cA

>>1003070

Not all syscalls are blocking. For blocking syscalls made by single-threaded applications, no copying is required. However, as soon as the caller is multi-threaded, even blocking won't help, as other threads could corrupt the syscal parameters while it is still executing. And for nonblocking syscalls, you definitely need to copy the input values. And if you copy strings, it is better to know the string length without having to read all of it.

>>1003232

Was meant for >>1003154

Any new operating system should strive for formal verification of its kernel.

>>1003243

>formal verification

Well, that's certainly reasonable, as every application has to assume that the OS works as intended. I'll seriously consider this.

>>1000546

>shared memory.

What's wrong with every process getting a pointer to write to its own public space as well as an array of pointers to every other process's public space?

>>1003490

More like having an internal TCP-like series of ports that are simple memory addresses that can be written to or read from.

>>1003549

Why not "sockets" named after the program they are representing? That way they would be self explanatory, and there would be a low chance to overlap.

>>1003017

Multi user for sure. I like the isolation users provide, which is admittedly a hack and should have its own dedicated permissions system, but still.

Talking about which, the permissions a program has are a very important matter. I think only the supervising user or a more privileged user should be able to cede a program their own permissions, via a simple config file the kernel reads upon launching the program. This should usually be handled by package maintainers to avoid bothering the user, but can be overriden by power users if needed. By default, programs have, at least, three permissions: writing to their own "open" area (think logs, temporal files, etc... anything non sensitive), reading from their own "closed" area (settings, which only the user or the program itself through some simple MAC/UAC mechanism can change; this is to avoid a program like Firefox going rogue if they ever manage to overwrite its about:config with malicious settings), and accessing the common area of the user, which would be the user home directory in unixland, minus the scattered config files. This way, programs can not alter the config of other programs (firefox can overwrite your .bashrc, let that sink in), they can not alter their own files without the user knowing, and they can still have full access to nonsensitive data, like media.

Bonus points if the OS also implements an "authentication server", by means of which programs can ask the OS to authenticate against a server or service using the passwords or keys stored by the OS, without the program ever knowing said password. Wouldn't be the first time I just copied and pasted my classmates' .mozilla folder in my desktop via ssh to access their passwords and copy their homework; regular programs shouldn't be tasked with something as important as storing passwords.

>>1002946

>I don't see any problem with C strings

Unless you have a revolutionary OS architecture to avoid stack and buffer overflows: don't. And even if you do, still don't. Let's not fuck up a new system with mistakes of the past, the base system utils and libraries shouldn't encourage developers to use a format that requires an O(n) operation to know the length of a string, and where everything can go very wrong with an off by one error.

>>1003551

>named sockets

Named resources will be one of the main features that allow the OS to be easy to program for. I think giving programs the choice to register aliases under which they can be accessed is the way to go. The alias is then the program's public namespace.

I think that it is important to prevent alias hijacking, but I have no concrete idea yet how that would work.

>>1003555

>Permission system

I think that to establish trust with the user, a capability-based and resource based permission system is necessary. Resources have their own permissions, as do system functions. The capability system would not have much runtime overhead, as syscalls only have to look up an entry in a capability table. However, the resource permission system would be more complicated, basically everything would have to support having a more or less fine-grained permission set.

>authentication server

It's a nice idea, because you wouldn't have to trust your programs to not leak any passwords if they cannot access them. Something like Linux's crypto API would be necessary: The program can request the kernel to instantiate a keyed hash function, encryption scheme or random generator, with the kernel-controlled password as key. However, every access to those functions would have to be a syscall because of the memory isolation. This is problematic, performance-wise. Also, the authentication server would need to support many cryptographic implementations and network protocols.

>>1003558

>C strings cause stack and buffer overflows

I think that is not the case. What causes buffer overflows is if you use C stdlib functions that have no additional parameter for the buffer length. The main difference is that 0-terminated strings are streamable, as you can append to a stream until you put the 0-byte, whereas in size-tagged strings, you need to know the size before even sending the first byte of the string.

I am currently thinking of a specification for the (binary) object notation scheme in the OS's API, which is to be used to pass values to programs or return them. There, an extra string type is included, but if a program wants to output a large string (say, multiple gigabytes), then it is infeasible to let it generate the whole string before returning it. I am inclined towards using 0-terminated byte strings with an additional escape sequence to allow strings to contain 0-bytes.

The streamable approach allows even large values to be passed between programs with little overhead.

OP here.

I improved the Object and process concept: Objects are written using the OS's object notation, and arguments are passed to programs as objects. Additionally, a process is passed an extra output stream to which it can output exactly one object.

Objects are inherently treated like streams, which makes it easy to pass them between processes (or even over the network, later on) without any complications, independent of their size.

Also, it seems that gitlab broke the links in the main README.md, you now have to navigate to the files over the code directory (Links in files inside specs/ seem to still work).

Every object stream can now only consume/produce a single object, if multiple objects need to be passed in one stream, a list can be used. Passed objects are read-only. I think this is a step closer to intuitive program invokation. However, I still need to make it possible to convert STDIN into a string / blob type Object.

>>1003717

>Also, it seems that gitlab broke the links in the main README.md, you now have to navigate to the files over the code directory (Links in files inside specs/ seem to still work).

Lol I am an idiot. It was all my fault. Fixed it.

>Non-CoC modern OS from scratch

Making a whole OS from scratch is a tremendous undertaking. Why do you think Terry Davis is regarded as a fucking legend?

>>1003752

t. defeatist

>>1003752

1. TempleOS was designed to be a toy to allow programmers to directly access the hardware. Common OS abstractions are removed in TempleOS to achieve this goal. This makes the OS much easier to write

2. Terry's schizophrenic non-PC rhetoric was endearing to the edgy imageboard crowd. The rest of the world see him as a schizophrenic to be dismissed.

>>1003919

As he used to say, "we are building a modern C64".

OP here (long time, no see).

Sadly, I have much to do, so I didn't get to work on the project recently. I did some thinking and came up with a few new ideas.

>Object notation in files

I am thinking about extending the Object notation to files, to have files also store only one object each (which itself can be a list of objects, of course). This would make saving and loading structured data much easier without having to write complicated file formats yourself. Files will no longer be treated as binary strings, but as structured data, and can be accessed as such. Of course, accessing files as raw data will still be possible, since files from other platforms do not conform to the object notation. If structured data is supported on the file API level already, then it will become much easier to have acceses such as (pseudo code):

$settings = open(settings.obj);
print("Debug: ", $settings["debug"]);

>Journaling and versioning

I was also thinking about journaling in the file system. Commonly, either there is no journaling, or only file system operations (such as copy, move, create, delete) are journaled, to ensure the integrity of the file system even in the presence of outages. I think that in addition to structural integrity of the file system, even file content integrity needs to be ensured. I think that journaling is not practical for file contents, however, a versioning system for files would solve that. Instead of modifying a file, only the changes made are saved, in a separate place (i.e., all modified blocks of a file are stored separately from the actual file). Then, when reading the file, the file's content is reconstructed from some kind of binary diff. This way, even if you crash while writing a modification, nothing really happens to previous versions of the file. Of course, there would need to be a merge tool that discards the previous history of the file, to free up disk space. Maybe one could even do this automatically, via setting a maximum history length in a file's options or something like that.

>File concurrency and transactions

I am not sure whether this is a good idea, performance-wise and security-wise. However, I think if a proper concurrency control system was introduced, then concurrent access to files should be possible without sharing a file handle. I see this as potentially useful for database-like files (key-value maps and arrays, mainly). Maybe the whole file API should be transaction based, but I'll have to think about that a little more.

>System calls

I also thought a little bit about system calls, and I think that they should be interruptible, i.e., by context switches or keyboard input. I am not sure whether this is the state of the art. It seems that in Linux, the current way to do things is to just restart the syscall from the beginning if it is interrupted.

>>1009497

Good choice. Having the operating system handle file formats and parsing them into a data structure is a good thing. File parsing is a common place where vulnerabilities exist.

>>1000542

>The old way that unix manages things is using the idiom "everything is a file". This clearly doesn't work in the modern age, so it should be replaced: everything is a web server. When you want to edit a text file, you wouldn't execute the file containing your text editor, passing the file containing your text. Instead you would visit the website of your text editor, and give it the url of your text file to edit. Rather than complex and unnecessary windowing system, you would have a simple web browser with a number of tabs. Rather than having to argue endlessly about programming languages and graphics toolkits, ui would be coded with html+css+javascript. Rather than having hundreds of different systems for ipc (signals, pipes, fifos, sockets, etc), communication between servers would be done with good old fashioned get and post requests. The shell would be superseded by the search engine.

Congrats you just described chromeOS

>>1009530

>file formats

I am not sure how to handle file formats, though. Something like a template, maybe a rule-based grammar could work here. You'd have a context-free grammar, which you can then pass to the OS while opening a file, and it verifies that the file matches the grammar. The grammars must be stored in some shared location, so that any program can use them. However, context-free grammars cannot validate everything, and more complex grammars are not trivial to parse. In the end, I think that it's not possible to have the OS do full file parsing. I think that for every file format, there needs to be a library that checks integrity of files. However, since the OS supports typed values inside files, you can have portability by also writing your byte order in the beginning of a file (or in its header). If you open a file with another byte order, the OS can then automatically convert numbers to your byte order, while keeping strings, blobs, etc. intact.

Another thing I do not know how to handle is errors: If you have streamed object passed to a program, (i.e., some on-the-fly generated stream of random bytes), and then, suddenly, there is an error in the format, the stream is shut down (on the writer's side). What happens to the program that received the object's stream? Will it also be shut down? Is only the read stream shut down? Does it just receive an error? Is it signalled with an error message, or will it only see the error when trying to read more data?

>>1000378 (OP)

Why not just contribute to or fork openbsd?

>>1009703

Have all file formats just be regular objects.

>Another thing I do not know how to handle is errors

Just do it like haskell. Make errors explicit in the return type of the function.

dont use fucking c and dont obsess over bell labs and their creations, and fuck all linuxism. if you have to use the terminal to use the computer you have fucking failed

>>1009705

That might happen, but first, I will work out my specification. If, in the end, OpenBSD fits my needs, I might fork it.

>>1009706

>Have all file formats just be regular objects.

That's what I was planning to do. However, existing file formats are sometimes too complex for extensive error checking by the OS. That's why I am still considering whether to add OS-side type checks or not.

>>1000542

>everything is web

oh great, the worst part of UNIX combined with the worse technology in existence. this nigger best be trolling

>>1003752

>Why do you think Terry Davis is regarded as a fucking legend?

no idea.

wait nvm i know why: because retards like you think he's a god because he's the only one not autistic enough to not be able to make an entire OS

Conceptually, does most of the difficulty in OSDev come from hardware support and driver code?

>>1010661

I guess it's one of the hardest things to do, since most of the hardware vendors don't give you their drivers.

But aside from that, the other big challenge is to design the system, as you don't want to end up with something like windows or unix.

>"Help me, LFS. You're my only hope."

oh wait...

OP here, with a new brainstorm.

I think the OS should have an encrypted file system:

Every user has at least one identity, which consists of a public and secret key, which are generated from his password.

Every file has its own (symmetric) key, which is used to encrypt its contents and name. An authenticated encryption scheme should be used for everything so that you can be sure that no unauthorised modifications were made to any file.

The file's name and contents are encrypted with the file's key (which is random). That key is stored in the file's metadata. For every identity that has access to the file, the file's key is encrypted and put into the metadata section. So if user A has access to a file, then Enc(A.pk; file.key) is stored in the file's key section in its metadata.

The list of available / used blocks needs to be accessible for every user, so it should not be encrypted. However, if there is a directory you have no access to, then you don't know which blocks on the disk belong to it. The disk itself can also be encrypted and protected by a password, but that has to be known to everyone who should have any access to any part of the disk.

Since file names are encrypted, you can store your own files in a shared directory, but nobody can guess the name of the file, its size, location (of its contents) on the disk, etc. This implies that file contents and file metadata are separate.

Since we use authenticated encryption, nobody can replace your files with fakes without being detected. It also makes it safe to share a drive over the network, as no information can be learned or manipulated by others. There also needs to be a central list of identities (or rather, their PKs) that appear on the disk, to save much redundancy. File access tags would then look like H(id.pk), Enc(id.pk; file.key).

The encrypted file system's security must be combined with further restrictions by the OS (such as enforcing read-write-execute permissions) to achieve security against malicious programs.

There is a problem with remote access though: Since only someone with access to a directory can see its contents, you cannot simply request a private file of yours from a remote drive, if the server cannot decrypt the directories, or does not know where the file is and how big it is. Maybe the directory contents, positions and sizes should not be encrypted after all, or only as an option. However, directory and file names would still be encrypted, although we would have to use deterministic encryptionfor that, which is not as secure.

>>1013117

>all this shit

https://gitlab.com/cryptsetup/cryptsetup

>>1013130

Didn't read through all of it, but this seems more like a disk encryption system, not an encrypted file system.

>>1002661

This is so intuitive. Had you worked with XEROX in the PARC, computing would have been far different and simpler, in good ways.

>>1013117

While we have you here, OP, when does the ISO get released? I can't wait to pull it up in a VM and try it out. It really does sound like a fine operating system.

black procedure thread?

black procedure thread.

>>1000485

[bits 16]
[org 0x7c00]
boot:
  mov ax, 0x2401
  int 0x15            
  mov ax, 0x3
  int 0x10            
  cli                 
  lgdt [gdt_pointer]  
  mov eax, cr0
  or eax, 0x1         
  mov cr0, eax
  jmp CODE_SEG:boot2

gdt_start: 
  dq 0x0
gdt_code:
  dw 0xFFFF  
  dw 0x0     
  db 0x0
  db 10011010b
  db 11001111b
  db 0x0
gdt_data:
  dw 0xFFFF
  dw 0x0
  db 0x0
  db 10010010b
  db 11001111b
  db 0x0
gdt_end:
gdt_pointer:
  dw gdt_end - gdt_start - 1
  dd gdt_start

CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start

[bits 32]
boot2:
  mov ax, DATA_SEG
  mov ds, ax
  mov es, ax
  mov fs, ax
  mov gs, ax
  mov ss, ax
  mov esi, hello
  mov ebx, 0xb8000  
  mov ah, 0x02
  call printWord
  mov esi, world
  add ebx, 0x00A0
  mov ah, 0x0F
  call printWord
  cli
  hlt

printWord:
  pushad
.loop:
  lodsb
  or al, al         
  jz .printDone
  mov word [ebx], ax
  add ebx, 2
  jmp .loop
.printDone:
  popad
  ret

hello: db ">logoOS",0
world: db "lmao",0

times 510 - ($-$$) db 0
dw 0xaa55

TBH this is me right now http://iswc.pw/

Fork Linux and rename it something else without including the CoC.

>>1013545

>I'm a LARPer

>I'm going to design an OS

ok kiddo

OP here.

>>1013579

>ISO when?

Right now I am alone and don't have much free time for this. I am still looking for partners (here and IRL), already found one potential partner. It will take quite a while to produce anything usable, as much time will be spent planning the whole thing to make sure it is good.

>>1013568

Thanks, I am glad you like it. I've only known windows and linux all my life, so I am pretty sure I didn't experience much diversity in OS features. This makes it hard to think outside the box. So if any of you know some good features from another OS that you would like to see in my OS, feel free to suggest it.

>>1013588

>black procedure

I have no idea what you're talking about. Only found walkley-black procedure, but that's most likely not what you mean.

inb4 b8

>>1013658

nice strawman

>>1000390

><remove CoC

Better yet:

<Fork loonix

<Remove CoC

<Port all the upstream changes that don't stink.

Now, who could possibly finance this work?

OP here.

I did some more thinking about RPCs, programs, and interactivity. Let's start with an example:

$db = async SQL(database.db);
$table = async $db->table("credentials");
print($table->select("*"));

Some programs or RPCs are inherently interactive ("SQL", "table"), and are designed to expect RPCs. In such cases, the async keyword could be made the default behaviour when calling (maybe by adding a flag to the executable, or when registering an RPC). This would save us a lot of effort when writing scripts that interact with programs. However, it would also create an inconsistency, as some programs and RPCs would block by default ("select"), and some wouldn't (depending on whether they are marked interactive). We would then still need to create an additional command that waits for interactive processes to finish, or to asynchronously execute noninteractive processes.

The system inherently supports lazy/halted evaluation of programs, as all returned values and passed arguments are streamed objects, so passing one program's output as another's input does not mean that the input program needs to finish before the other can start, and might in fact be halted until the other program reads data from the output stream. We'd need some kind of barrier or join operation to actually ensure that a program finishes before starting the next program. I think it would be good to make ";" an implicit barrier, and maybe add "," for jobs that can be run in parallel. Parallel would mean that they are started in the order in which they were written, but the next program may be started the moment the previous program is instantiated (as soon as its output stream and PID exist).

Maybe block statements should also act as barriers, and similar to C++, destroy variables declared inside. I am not sure though, whether it would be more reasonable to wait for all execution started inside the block statement to finish, or whether to just send some kind of "destructor" message to all programs that need to finish, and then just continue on with the rest of the code. This needs some further consideration (how to handle interactive and non-interactive programs, etc.

>>1013736

Given that most of the work is already being done by others, it wouldn't cost much to maintain a website and Gitlab repo.

>>1013827

Let's be honest here for a moment: The CoC does not magically make the Linux code bad (I am pretty sure that the quality should more or less stay the same). So if you really want Linux, you can keep using even the CoCed version.

However, seeing that the Linux developers became cucks, this is a good opportunity to make a cut and switch to a completely new, not "good enough" OS / kernel. As Corporations are pushing to drive out the people who made Linux what it is and take control of free software, we should abandon Linux and switch to a better system. The good thing is that Corporations are only interested in "good enough" systems, so they will most likely leave us alone: It's not profitable for them to do something "the right way".

That's how I see it, anyway.

>>1013817

select shouldn't cause it to halt. The print function / program should wait until the entire thunk is evaluated so it can extract the strings.

Parallel functions should be run as

(a, b, c) = (fun1, fun2, fun3)

>>1013838

>we will make an OS better than Linux and Windows

>doesn't even have a fucking LOGO!

lmao

How do you expect me to work on an OS for free when there is no cute anime mascot to motivate me?

>>1013896

>>1013900

There was one artist fag (>>1002668) that wanted to make a logo, didn't hear from him again. ;/

>>1013896

To design a good operating system you don't actually have to implement it. Since there isn't even a concrete plan of the entire operating system, it's reasonable for the process of programming it to not have started.

>>1013884

>select shouldn't cause it to halt. The print function / program should wait until the entire thunk is evaluated so it can extract the strings.

Not exactly. The script only continues after select() and print() finished. However, print() runs while select() runs, and prints the output as it is generated (on the fly). Otherwise, if select() outputted a huge string, it would kill the machine to buffer everything.

>>1013908

You are misunderstanding me.

$db = async SQL(database.db);
$table = async $db->table("credentials");
$results = async $table->select("*");
print("B");
print(results);

hiiiiiii thar lol ^,^

i'm a transgender girl just getting into programming but im not the annoying type LOL! xD anyways, just lettin' u nerds know that im 100 procent on board and hope that once i find an alias and change my typing style, if anyone finds out that im a cute transgender girl, that there will be no bully plz

the point of this is to enact meritocracy instead of social justice virus, so it'd be totally coolio to ensure that hot traps with good code are accepted happily and that anyone with bad code is sent to the chamber of dooooooom! ^_^;;

OP here.

>>1013910

>In your original proposal, it would not print "B" until $results was completed.

Please note that in my example, "select()" was not marked "async".

Technically, "async" would return a handle, such as a PID or similar, which can be used to interact with the execution of the invoked program / RPC. I thought about introducting the "await" operator to get the return value of an async operation. Then it would look as follows:

$db = async SQL(database.db);
$table = async $db->table("credentials");
$results = async $table->select("*");
print("B");
print(await $results);

>>1013913

Hi qt, can you recommend me some good programming socks? I already bought myself a buttplug this christmas, so I am almost good to go. ^_°

>>1013914

Cute progsocks? I just bought some pink ones, along with a full outfit set, including pretty little cat ears and a tail! The most proper girl is a girl that finds the most skilled nerd, and serves him utterly, while helping him find a female to breed with.

Normal females aren't really good companions for nerds, so it's up to us traps to ensure that not only are nerds not lonely, but that they also have a charismatic companion to net them a proper female for child surrogacy reasons. That way their genetic lineage doesn't die! Yay for being both skilled, and having a family. If a nerd can't talk to females, then I will, such that we both end up with a family, so that we don't have to die alone.

A trap is a necessary component for any technical project as well, for morale reasons. A bad, wicked trap can do the opposite, like the hideous code-witch Coraline. But me? I'm much cuter, seeing as I type anonymously here, and you can imagine any sort of cutie that you want, seeing as you won't see my face ever. So hopefully I can get in good with this project, and help see the rise of a new Operating System paradigm that not only defies the corporate wasteland of HR obedience, but also creates a platform upon which beautiful, elegant code can be run to do glorious things.

>>1013916

The idea of a neckbeard LARPing as qt for morale warms my heart. Thanks anon. I'll think of you as my muse until we have a qt anime mascot for epOS.

Enough derailing, don't want to ruin my thread.

There are multiple components of any proper OS that are required. Now, we do not need to play "Let's be Linux Windows X."

We don't need to copy our competitors, if we are forging a new paradigm. What we need now is simple, and so let me write a list of some elements that I think are required. Most will be obvious, but it's still good to have it in writing. If you disagree, then let me know, and if you agree, then let me know. Let me begin.

A CLI.

A platform upon which to run ASM/C code binaries.

That platform will easily be upgrade via third-party software to also run any sort of binary package written in any language.

Driver support must natively include mouse, keyboard, touchscreen, game-controllers, monitors, popular video-cards, USB data storage devices, and network interfaces.

An OS must be compatible with different combinations of hardware, as well as the three popular architectures of CPUs.

This OS must be advertised to developers as soon as it is ready. Let's port Nethack, Descent, Doom, Quake, and yes, even fucking Minecraft, to it as soon as possible, and propose that this OS is not only a techy-hobbyist platform, but also a place for true gamers to find respite from the console wars and decline of modern AAA PC gaming.

It's ok to have sweaty armpits as long as we're onboarding excited new developers, right?

Let there be a software manager as Linux has, and ensure that as much GPL software is ported as possible, however, let us play a nice Apple move, and ensure that all software on the main package manager is vetted by us, to ensure that it is as bug-free and useful as we desire.

This OS must be considered, "Enlightened." If DOS was gen I, after the primitive OSes that came before it, then popular GUI OSes after DOS were gen II, and that basically makes OSes like Android gen III. Windows 10 and CoC Linux can also count as gen III. So we need to be Gen IV.

Thus, a name I propose is Genevieve. "Gen IV."

Gene refers to life-code, which is a great start, and "Vivian" was the name of the original Gamer-Gate mascot. I'm not a gamer, but I was part of the original exodus to 8chan after 4chan became a serious censor-pit cesspool.

So we have a chance for a (controlled) edgy fork called Memevieve, and a popular fork called Genevieve. The name is a classic call-back to the legend of King Arthur, which of course, is what this world needs: A king summoned by a wizard to right what is wrong with the world. And that is what this project is meant to do. All branches of modern computing have merged upon "Corporate Enslavement and Government Surveillance." We must free computing and give it back to the hackers and rebels, and to do this, we need a truly new beginning.

So let's have it be Genevieve.

If these points can be agreed upon, or modified with improvements, then we can break them down further into actionable points upon which to begin actually coding. Let me know what you think. ^_~

>>1013914

I honestly think having an async keyword is dumb. It should be async by default.

>>1013827

>most of the work is already being done by others, it wouldn't cost much to maintain a website and Gitlab repo

>>1013838

>The CoC does not magically make the Linux code bad

The CoC is a sign that suspicious stuff like intel's hardware RNG will get introduced (or other stuff Linus would yell at just a year ago).

Which means all the changes need to be reviewed by a non-affiliated team.

And that is a lot of changes.

And soon enough the security backports will become less trivial because of the skipped changes.

>>1014016

>I honestly think having an async keyword is dumb. It should be async by default.

Maybe in a very pure functional language;

but otherwise 'async' is helpful to indicate where the execution might switch to other coro, possibly changing global state, as opposed to non-i/o functions where you don't have to think too much about interleaving. Also, performance.

>>1014033

>Also, performance

Do you know that *NIX is async by default too? It just waits for everything to terminate when hit enter / encounters a semicolon.

>>1013920

>CLI

Agreed.

>Binary execution

Agreed. However, I would not run standard C, but C with a different main function signature, as written in the specs (I think it was the process page).

>Driver support

Tbh, I'd first work on the technical stuff and then add drivers. Of course we will need them eventually, but it's not the most important thing. Even basic video and text mode would be sufficient at first.

>Advertising and porting games

That's way into the future. Of course, it would be nice to be able to play games on it, but I think that that's a double edged sword: The gaming industry will push users to install proprietary drivers, to get a few extra FPS or some special VFX, which is how the whole system begins to be compromised. I also think that the current gaming industry is at least as bad as the rest of the software industry, save a few indie studios. They long since stopped making fun games, and are now milking their customers blatantly.

>Sweaty armpits

Checked ;)

>Software manager

Yeah, seems important.

>strict auditing

Well, I don't really have the time for it, but as the community grows, I think that would be good.

>Enlightened / Gen IV

Well, I don't have a fixed vision for a fourth generation OS.

However, I have a proposal: I am heavily into decentralised/P2P and crypto. I think we should provide many privacy-preserving tools:

- A P2P file sharing program (probably one of the existing ones),

- TOR,

- A P2P image board / social network,

- A P2P chat / voice chat

If we have all these features covered, then users do not need to install any third party software to do what they need.

>Genevieve

You mean French pronunciation? Not sure if I like that. Since I already labelled it epOS, I take it you don't like that name?

>Vivian James

Hmm, not sure if I like it. I mean, she's cute and relatable, but I think it would somehow miss the point to take a gamer mascot for an OS. I think we need a mascot of our own. Something about not caring about / opposing current corporate culture, censorship, political correctness and surveillance. Cute and embracing our autism maybe. (You may come up with better suggestions, this is just from the top of my head). Or maybe something like a pair of mascots: A cute one, and a heresy purger fighting against proprietary software and corporate culture. Maybe a wizard with his apprentice witch?

>^_~

D:

>>1014016

>>1014036

I don't think that async default is good: The shell should be easy to use, and asynchronous execution is an "advanced" concept: to someone who just started programming, it is much more intuitive that everything they write gets executed in that order, like in almost all other programming languages. Furthermore, it gets more complicated, as you have to know whether two programs are allowed to concurrently execute or not, based on their side-effects.

>>1014029

Well, that's true, but that should not have happened yet. If I were (((them))), then I'd wait for a bit until all this CoC outrage dies down a bit, and then introduce backdoors bit by bit. However, I agree that the future versions of the code will without a doubt become more insecure as corporations get more power.

>>1014070

>and asynchronous execution is an "advanced" concept

I do not degree with this. Normal computer users are very use to having multiple programs running at the same time. *NIX users don't seem to get to confused when they use asynchronous execution. *NIX even let's you pass lazily evaluated strings between processes.

>everything they write gets executed in that order

That would still happen. You just don't get the guarantee that the second application will start after the first finishes.

>as you have to know whether two programs are allowed to concurrently execute or not, based on their side-effects

It should always be safe to run any two programs concurrently.

What is the point of starting a new project from scratch? If you really wanna accomplish something fork Linux and start heavily modifying it (like changing the monolithic kernel design to something else). Like this guy said:

>>1000535

Every mainstream OS is basically built upon legacy code from the 80s and 90s, which means that they are still very limited at their core. The time to make a new OS from scratch that doesn't suck is not here yet, we are still stuck with flawed legacy operating systems that just have layers of new garbage added on top of them because no one seems to care or notice.

>>1014089

>Linux and start heavily modifying it (like changing the monolithic kernel design to something else)

Better off starting with bsd

>>1014076

>async is not advanced

As I said, out of the perspective of a non-expert, async is way more complicated than just sequentially executing a program. Making this the default behaviour will require more effort to program sequential programs. It also assumes that almost all programs will be RPC-interactive, which I assume will not be the case.

>>1014089

>What is the point of starting a new project from scratch? If you really wanna accomplish something fork Linux and start heavily modifying it (like changing the monolithic kernel design to something else).

Just because I will most probably support x86, does not imply that I restrict the OS's features. Almost every feature can be emulated, even if there is no hardware support. Although it might make performance worse, it will create forward compatibility for the time when better architectures which have native support for it are released.

Op here

Where's http2://NonCoCLinux.org/notgit/ ?

OP here.

Right now I am reworking the article about the shell language. I am currently trying to figure out how powerful to make the shell language. If I want it to be a scripting language, I think that I should keep it simple: dynamic typing, no classes / custom records, no function overloading / type matching. However, I think that making the language more powerful would have many benefits, such as an increased productivity and safety (through something like static typing, type matching, classes / records).

What are your thoughts on how powerful the shell language should be?

>>1014429

>Where's http2://NonCoCLinux.org/notgit/ ?

Enjoy https://gitlab.com/GXA8qGNp9971/epos

two hundred and thirty posts and it's just a shitter Idea Guy getting pissy that he can't get free slave labor from a bunch of rednecks

>>1014438

Shells are trash. Replace them with something else entirely.

OP here, trying to figure out whether to stay with the all objects are streamed approach for the shell. The problem is illustrated in the code below:

var $result = ./generate();
./something($result);
./something_other($result);

If I stay with the all objects are streamed approach, then this implies that every value can only be processed once at most (or multiple times, if done in parallel, and the slowest consuming program would limit all the other programs), and that values should never be actually stored within a variable, and only directly be passed to another function, like this:

./something(./generate());

I think that the following might work: Variable declarations can be done in parallel (using "," instead of ";"), in which case the value is not really cached, but the program is directly piped into the program it gets passed to. However, if a ";" occurs, then we need to force the execution of the program to finish, and also to cache the whole contents of the value. A parallel version would then look like this:

var $result = ./generate(),
./something($result),
./something_other($result);

I think that this may have to be done via a "drain" operator, that can be used to pass a value as a stream to a program, and the value is deleted after use. It is similar to a delete operation, except that it allows one last usage of the value. Using this new operator, the first example would look as follows:

var $result = ./generate(),
./something($result);
./something_other(drain $result);

This is obviously an optimization technique, but can be very important at times. For small values, this can be neglected without causing any trouble.

Also, I think that "," and ";" should be nestable such as this:

a(),
(b();
 c());
d();

>>1014481

>Shells are trash. Replace them with something else entirely.

If you don't want your whole computer to only run one gargantuan, monolithic program, you will need some form of shell, that allows compiled programs to be composed / combined, and controlled. I don't really like this either, but I don't see a third way here. But if you have a third way, let me know. I would actually like to have a compiled programming language (like a custom C or C++ version or something), but I think it would be too much work. Maybe if more anons joined in on this or something.

P.S.: Do you guys even read my ramblings?

I will not stop, even if you tell me to.

>>1014438

It should have static types. Dynamic types make it more complicated on the programmer as they are the ones that have to make sure that two things are compatible rather than having a program tell them they are compatible.

>>1014476

based and saged

>>1014488

>It should have static types. Dynamic types make it more complicated on the programmer as they are the ones that have to make sure that two things are compatible rather than having a program tell them they are compatible.

I am actually in favour of this. However, I think that this will easily result in a full-fledged programming language, because if I add static typing, then I might as well add classes, checked type casts (Object → class) as in typescript, etc. This will add a significant of work to my to-do list.

But depending on how the project fares, I can still decide whether to make it a full-fledged programming language, or whether to keep it on the level of javascript. I think I will specify it as statically typed for now, I can always change that later.

>>1014493

Well shells are a programming language. UNIX just offers you a bad one to use. LISP machines let you use all of lisp from the listener. There was even a C listener you could purchase that let you use C to do stuff on the fly. (A shell is a listener with less functionality) TempleOS had a similar thing, but used HolyC instead of regular C.

I respect your enthusiasm on this project, anons. I will drop my 2 cents.

In my opinion, by default a process should only be able to compute and execute only the most basic syscalls, like calling EXIT. Any bigger syscall should be given to a process by a capability (or by passing a capability by another process). Having a uniform FS is already too big of a security flaw - one that is currently addressed by the Google Fuchsia OS. There should be a tool to inspect the flow of capabilities within the whole OS. One should also think about network programming from the beginning, because big systems often encompass more than 1 machine - plan9 had a bunch of wonderful ideas.

The multitude of graphic libraries on Linux systems while none are easy to use causes an interesting phenomenon - almost no one writes graphical programs/demos/etc. Compare that to the state of Windows or Mac OS programs.

>>1014499

I am not sure what you mean by listener. What I am trying to do is to make the shell more like a real programming language. However, I am not yet sure whether to give it full capabilites of normal programming languages, or to keep it domain specific, since you can offload any calculations to real programs.

>>1014631

>Syscall capabilities

I think that this is not fine-grained enough, but it's a good start. For example, some programs should not be allowed to access any files at all, but others should only have access to some files or directories, and not others. Some programs should only be allowed to have connections to machines in the local network. This means that every syscall needs to be unlocked, but that inside every syscall, further capabilities are needed for fine-grained permission control. This obviously requires a more complicated system than UNIX's sudo, but I think that if you enter required capabilities into the application header, you can make it easier. And some permissions might only be needed rarely, which would require a runtime capability management system, where you can temporarily enable / disable capabilities.

>by passing a capability by another process

Do you mean that one process calls another process, and it has a subset of the capabilities of the calling process?

>Having a uniform FS is already too big of a security flaw

I don't see what the problem is here. I think that most current FS are not suited to fine-grained permission / capability control as needed by our OS.

>network programming

I think that the OS should support sharing resources, such as the file system, processes, etc. If you have authorisation, you can then treat resources on other machines as if they were on your machine.

>The multitude of graphic libraries on Linux systems while none are easy to use causes an interesting phenomenon - almost no one writes graphical programs/demos/etc. Compare that to the state of Windows or Mac OS programs.

What do you suggest?

I also think that a program should always have two consoles: one for OS I/O and one for the program's I/O. If you need to enter your password as authorisation, the program could just emulate the system's prompt to steal your password. This would not happen if that always happened in a separate console that can only be accessed from within syscalls.

I also think that every program should have a userspace and kernel space stack, because this would make syscalls interruptible, and allow longer syscalls, i.e. one that waits for the user to input a string or something like that (i.e., password), without blocking everything (afaik, in UNIX, a syscall is aborted when it is interrupted).

Is the captcha is getting harder to solve, or is it just me?

Continued specifying the shell language.

I introduced a basic type system, worked out variables for the most part, and added basic functions.

You can read about it in the Shell and related pages.

>>1014764

What if programs in this OS can know what capabilities they have by inspecting something (UNIX style systems would probably have a place with a file describing the capabilities, or multiple files representing the present capabilities)? I personally think a directory like /runtime/capabilities, with several booleans would be pretty cool, and each program should have their own view. Speaking of which, what about filesystem views? There may be a "real" filesystem underlying the entirety of the system, but each program has its own "root", and get a virtual view of the real filesystem, declaratively defined and built on each boot, which would allow programs to operate on "clean" slates where no other program can interfere with their operation, unless specified (by defining a common directory, for example), and to ensure they do not go around looking where they should not have to. Not only that, but having views shpuld make you able to conpeletely rearrange the way the FS is presented, while actually having a completely different underlying structure.

>>1014839

>LARPer tells us he doubts other people can do X

hmmm really makes me think

>>1014849

>no u r the LARPer

How about you proof that you aren'y a LARPer?

>>1014860

Ok. I haven't written an OS. Other people have written an OS.

There ya go. Pretty fucking easy to not be a LARPer.

>>1014863

>I haven't written an OS.

LARPer. Exactly as >>1014839 states.

>>1014867

Not everyone is a faggot anon. Stop projecting.

>>1014869

Everyone on /tech/ is. Stop lying to yourself.

>>1014870

People who are ill think everyone else is ill. Seek help for your neuroticism.

>>1014875

Stop trying to detract from the fact that /tech/ is all talk and no action. Whether or not I am a LARPer (Protip: I am, just like the rest of /tech/) has nothing to do with the fact that /tech/ will never create a non-cocked OS.

>>1014879

If the OS is intended to be "universal" as in it is supposed to run on any kind of personal computer with the myriad of PC hardware devices available today, I will predict that /tech/ will not produce such an OS. Such a project requires year upon year of dedicated programming work. If the OS is targeted to specific hardware platforms without regard to being conformant to the wider range of hardware (e.g. /tech/ approved Thinkpads only), then such an outcome is more probable for /tech/. Either way, my personal prediction for this project is all talk and no action.

>>1014882

>he agrees with me

LARPer

>>1014879

>I am a LARPer

lmao no way

>>1014884

yeah, you are

>>1014886

You admitted to being a LARPer. You are LARPing as a plebbitor who hates LARPers but you are actually a LARPer too scared to stop LARPing and try doing something so you just LARP as a LARPer hating LARPer.

Sad!

OP here. Please stop derailing my thread.

People who are interested in this will have a harder time keeping up with my project. We already had the whole LARPer discussion, and agreed to disagree on this. So please stop now.

>>1014844 Sorry, didn't see your post between all the LARPer posts.

I think that the OS should offer a Capability management and detection API, where each capability is either an enum constant, a string or something like that, and you can just query it to receive a list of granted capabilities, or query a single capability to detect whether it is present.

>Speaking of which, what about filesystem views?

I think that the file system should only contain files. However, every process should also have magical directory of its own, which can only be accessed by itself and maybe child processes or something. I still have to figure out namespaces, which are to be used to expose RPCs, files, sockets, etc. to other processes. I think that every program should have its own private, protected and public namespace, in which it can allocate data. The namespace API should then allow sharing resources with other processes, either by giving them explicit access to a specific resource, or by placing a resource in the public / protected namespaces. Public can be accessed by everyone, protected only by child processes, and private only by the process itself. This kind of access control works okay for OOP, so I think we should be able to extend this to the process model without fucking everything up.

However, the namespace problem is not trivial: Should multiple instances of the same executable have access to the same private directory, or should they have separate copies? If you have separate copies, then how about private data persistent across multiple executions? I think a good idea could be that every executable has a private directory that is shared among all its instances, but every instance of it also has an additional directory of its own. This way, programs can be written to support multiple executions of the same executable more meaningfully.

Maybe the same should be done for other resources: If you open a socket or file, you can either open it in your own private instance, or share it among all instances of the program, or make it public to all processes, etc.

>>1014920

Just do what Fuchsia does: https://fuchsia.googlesource.com/docs/+/HEAD/the-book/filesystems.md

>>1014922

I don't think that the file system should be a process for several reasons: The file system is an integral part of the operating system; Without one, we cannot even load applications (they are just files, remember?). I also think that there is no harm in commiting to a single file system that suits all our needs. If you still need multiple file systems, you can still create your own servers for it like Fuchsia wants, but at least one FS needs to be supported natively. And that FS should be our own, with all the features the OS needs (such as capabilities, etc.).

>ThinFS: A FAT filesystem written in Go

>Go

Now you're just trying to trigger me.

>>1014928

The OS shouldn't care about where an application comes from.

>muh thinfs

<It serves a dual purpose: first, proving that our system is actually modular, and capable of using novel filesystems, regardless of language or runtime. 

>>1014942

>The OS shouldn't care about where an application comes from.

What are you saying here? I never said that you can only load applications from the file system. I think it is also reasonable to load applications from other machines, or to generate the application dynamically, like directly executing the output of a compiler, without writing it to the hard drive first. However, to load anything from a file system, you first need to support a file system. This means that you must bootstrap support for at least one file system by putting it into the kernel.

<It serves a dual purpose: first, proving that our system is actually modular, and capable of using novel filesystems, regardless of language or runtime.

I am triggered that people write a file system for an OS in a meme language, and then call it thin.

>>1014764

>I am not sure what you mean by listener

A listen loop is the same thing as a REPL.

>>1014839

It's rather most people can't afford to put away the time needed to make an OS that would be worthwhile to have.

>>1014997

I would make the shell parse a single statement (until the ";"). This still allows doing multiple things at once, if you separate them via ",".

>>1000539

>The best way to replace white people with shitskins is by sneaking shitskins into white countries.

Yes, Shlomo. We know that's your modus operandi. Now please kindly gas yourself.

>>1015151

Another libcuck tranny chaser is obsessed with 8chan. wew lad

>>1015153

lmao a vegan too

>>1015151

reddit can't into distinguishing shitposts from real posts. I guess he was referencing >>1000419

>Hey... let's LARP that this OS is already written!

>hey guys, MrCode has just uploaded the rewritten TCP/IPv8 stack! ...and it's only using up 128 bytes of machine code! AWESOME

It's a picture of people LARPing. He actually says he's LARPing in the first sentence. TCP/IPv8 does not exist. And 128 bytes for a network stack is obviously impossible. And yet, he goes on to post about this on lellit, under his usual user name, revealing his power level to be close to absolute zero.

>>1014764

What I want to propose are robust sandboxing capabilities enabled by default. Let's see an example with some UNIX shell apps:

cat a b c > d

The cat binary needs an access to files a, b and c. In my opinion it's a flaw and the cat binary should be given FDs (like with "d" file). Otherwise this binary doesn't need to do anything beyond FD mangling. Most standard UNIX shell apps can be simplified to this.

Why is this important in my opinion? Would you run an untrusted application downloaded from the Internet? On Linux obviously not. But if you could guarantee that such an app wouldn't extract any private information without your EXPLICIT permission and the most harmful thing it could do is an infinite loop? If we want that to happen, then exposing an app to a global filesystem is a total no-go. Maybe it would be possible to do some mapping system:

./app map:(/local: ./lib/, /lib/libc.so, /auto)

Where /auto would work kind of like this to an app:

$fd = /auto/save_file

And it would show a dialog window (from a privileged context) to user to pick a location to save a file and return the fd of file opened to write.

>>The multitude of graphic libraries on Linux systems while none are easy to use causes an interesting phenomenon - almost no one writes graphical programs/demos/etc. Compare that to the state of Windows or Mac OS programs.

>What do you suggest?

An easy and integrated visualisation and controls library. On Plan9 the teminal is actually a scratchpad and is accessed with a filesystem interface. TempleOS allows you to draw graphics and even 3d models. I don't think it's really a great idea, but an ability to do such a call at least that easily is IMO a must:

$window = new Window("Graph",300,400)

$window->line((0,0),(300,400))

>>1015168

>robust sandboxing capabilities enabled by default

Extending my idea from >>1014920 programs could only access files inside their private namespace, and any additional accesses need to be whitelisted. So, by default every program has full access to its own sandbox, and everything beyond needs to be allowed explicitly. Maybe you could pass files to programs and also give them capabilites, like:

./app(file(config.txt, "r"))

>graphics example

I think that this is right, as it would allow you to create a window from a shell script (i.e., add elements to a window, handle events etc.). As the RPC system is quite powerful, you would only have to add these functions to the window manager's RPC interface. However, I am not sure how to handle onclick callbacks: We'd have to pass shell code to an RPC that would have to execute in the same context. So, somehow the shell also needs incoming RPC support, so that my shell code can receive calls from programs it started.

>>1015499

cmiller1 had some 12k karma or something, I bet he just killed himself.

>>1015502

>11 years of reddit, and one post is all it took to ruin it

kek

>>1000433

It's called a microkernel