/hobby/ - Hobbies

Entertainment, Education, Games, etc.

catalog
Mode: Reply
Name
E-mail
Subject
Message

Max message length: 8192

Files

Max file size: 20.00 MB

Max files: 3

Password

(used to delete files and postings)

Misc

Remember to follow the rules


(99.85 KB 1200x851 Bk0010-01-sideview.jpg)
Code of Conduct(s) Comrade 09/24/2019 (Tue) 23:49:55 No. 923
Perhaps a declaration of technical principles would be a better term, but regardless the necessity of finding a means (beyond licenses out of necessity) to secure our software from outside meddling seems to be all the more essential the more I think about it. There are approximately 90 CVE's (70% due to memory safety) in each Linux kernel major version, many of which remain outstanding even after moving to the next version, with the average lifespan between 3 and 6 years for "high" and "critical" bugs. The Linux kernel is now approaching 28 million lines of poorly documented code, making it completely beyond what a actual audit is capable of assessing, beyond comprehension. More than this the development of the kernel and funding of the foundation are almost entirely in corporate hands. Linux is but a example, every large component of major infrastructure (and rest assured if it's major infrastructure it will become large) suffers from similar plights.

What I'm not attempting to advance here is the suckless philosophy. In my opinion suckless goes beyond attempting to restrict the scope of their projects to an obsession with SLOC to the point of harming correctness and completeness (for a sound list of necessary features see here: http://www.loper-os.org/?p=284). They do not document their programs, following the mantra that code is documentation (which is true but insufficient). Additionally they fail to critique the accepted protocols and divisions of applications, which would allow them to not only make more correct complete software, but also to make in aggregate simpler software. As a example why make a separate windowing system, terminal multiplexer, terminal emulator, and text editor when these things could all be combined as extensions of one another. Why separate your text editor from your web browser? Why work with text streams and the file system instead of having a single address space? Why take X-Server for granted rather than building of Linux's frame-buffer.

What issues is it that I'm pointing at here exactly:
a) scope creep
b) illiterate programming
c) unquestioned assumptions (primarily those given to us by unix)
d) over-optimization (understandability, and completeness should be prioritized over micro-optimizations)
e) insecure technologies (for example unassisted manual memory management, and unchecked type wraps)
f) incomplete software (corner cases handled etc)

Can you think of any more, or a consolidation of the terms listed here?
(3.63 KB 123x113 boomer.jpg)
let me larp as boomer senior enterprise architect just for the sake of argument.

LOC of linux 'kernel' is not exactly good indicator as vast majority of them would be for support new devices. Granted we suffer major memory management related incident here and there but such is a nature of system software. You may shill formally verified toolchain & kernel but effort required to adopt them by adding currently required features will defeat the entire purpose.

The reason why suckless philosophy will remain as meme beside dwm and few killer toys is because of their failure to recognize the simple fact that 'life is messy'. You can project your mathematical puritan ideology on engineering discipline all day long but if you cannot keep up with industry's demand, you will remain irreverent hobbyist.

a) I like emacs. emacs survived few decades. It will survive another decades.
b) time it takes to write serviceable documentation may as well be spent on writing better code although we are all envious of OpenBSD's documentation effort .
c) "those who try to fix UNIX will end up with worse version of it" forgot the actual quote but you get it
d) human mind admires complexity. especially when things do work out the way it was intended.
e) if you touch such undefined behaviour, you will break a lot of things. A LOT OF THINGS [spoiler] but ofc no new software should be written in C/C++ unless you have to be on baremetal [spoiler]
f) incremental development is a thing.

*pops open semen can*
>>776
>LOC of linux 'kernel' is not exactly good indicator as vast majority of them would be for support new devices.
Even considering just the non-driver components of the kernel it's several million lines with far more options than necessary. Another measure would be ~40 syscalls for Plan9 compared to Linux's 328, and less than 10,000 SLOC compared to Linux's several million for even just the core.

>Granted we suffer major memory management related incident here and there but such is a nature of system software. You may shill formally verified toolchain & kernel but effort required to adopt them by adding currently required features will defeat the entire purpose.
Ada has had all required aspects since the 80's. The effort required to adopt them seems to depend entirely on how much you want to do.

>You can project your mathematical puritan ideology on engineering discipline all day long but if you cannot keep up with industry's demand, you will remain irreverent hobbyist.
I'm not really interested in industry demand, and I'm not supporting the suckless philosophy as I mentioned. Being a irreverent hobbyist so long as the software I personally run is secure and pleasant to use is perfectly fine to me.

>a) I like emacs. emacs survived few decades. It will survive another decades.
I love Emacs (I'm running firefox in EXWM currently), and what I'm suggesting is really a universally integrated experience like Emacs, but with a greater demarcation of components and extensions (as in installed after Emacs). Emacs doesn't need to ship 3 terminal emulators, and a tetris game.

>b) time it takes to write serviceable documentation may as well be spent on writing better code although we are all envious of OpenBSD's documentation effort .
This is a fair point but much of what I'm trying to say is that we should strive for complete programs which rely on relatively little. Program less.

>c) "those who try to fix UNIX will end up with worse version of it" forgot the actual quote but you get it
This is not true, Lisp Machines were not UNIX. Arguably Emacs is not UNIX.

>d) human mind admires complexity. especially when things do work out the way it was intended.
Ought Is distinction.

>e) if you touch such undefined behaviour, you will break a lot of things. A LOT OF THINGS
It's not clear to me what you mean by this.

>f) incremental development is a thing.
Incremental development is fine, just don't ship until your software doesn't have edge-cases not covered and other sorts of incomplete design or implementation.
>>776
Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Thou shalt not write an Electron app.
Or else.
>>779
>Thou shalt not write an Electron app. Or else.
Despite being entirely within my intentions, this is oddly not excluded from the list I made. I think reformulating the list in a more traditional manner would solve this though:

Complete - We should strive to make complete programs, this is a program which has solved the original problem it set out to solve and as such no longer needs to be developed. To achieve this quality our programs must have a clear, specific, and achievable purpose set upfront. To achieve our other goals this means that time must be taken initially to consider future program interactions and arrive at the simplest design which achieves our objectives in the aggregate.

Understandable - We should strive to make understandable programs, a program which can reasonably be expected to be understood by its users. To be understandable we must strive to make the simplest program (including libraries) capable of fulfilling our objectives. Simplicity should be prioritized over optimizations unless our objectives are not met due to performance. We must also program literately while keeping our documentation up to date with our source.

Secure - Data should only be sent from a users machine at their express command. Measures should be taken to secure users from antagonistic forces attempting to take their data without their express command. Technologies which are insecure, or promote insecure behavior should not be tolerated.

There's probably a better formulation to be had. Thoughts?
(107.35 KB 581x387 trztb.jpeg)
>>780
software security is frustrating because most systems are build on black box technology and that means you are at best building a sturdy house above a potential sink hole.

Cockshott made a video
>https://www.youtube.com/watch?v=Mw_WQRPIBNU

he more or less argues for abandoning the concept of building computer fortresses with reactive defences and go for systems that aren't even compatible with code you don't want run.
>>781
>Software security is frustrating because most systems are build on black box technology and that means you are at best building a sturdy house above a potential sink hole.
This is half true. Depending on the complexity of the device we can verify that individual instructions are operating as intended and unexploitable. The issue is when you have more complex instructions like a RNG instruction, or hardware cryptography, or execution of non-user code, or out of order execution, etc. These things have all been proven to be used by intelligence agencies in the past against users. Perhaps some RISC-V CPUs will be the solution to this issue, for now the best we've got is >>707.

>He more or less argues for abandoning the concept of building computer fortresses with reactive defences and go for systems that aren't even compatible with code you don't want run.
Reactive defenses are silly but he's attacking the wrong things here. In terms of viruses the issue is idiots downloading them directly, arbitrary code execution in the form of javascript, and buffer overflows from the poor design of C, C++, and our ISA's. Additionally viruses are a extremely small part of the broader issue in my opinion. The intelligence community has compromised entire cryptographic standards, RND generators in CPUs, hardware cryptography solutions, software cryptography solutions, and just about every piece of large major infrastructure. This is a direct product of the unverifiablity of the programs we run, we must be able to understand and assess the programs we run if we are to have any hope of being secure. It doesn't matter if you don't have viruses if all the software you run is completely insecure.
>>780
Maybe this should be more of a single manifesto than a neatly divided set of principles. They all seem to blur together because I guess what I'm trying to avoid is the impacts of one thing.
(84.90 KB 930x304 image.jpg)
My code of conduct:
We stand for active ideological struggle because it is the weapon for ensuring unity within the Party and the revolutionary organizations in the interest of our fight. Every Communist and revolutionary should take up this weapon.

But liberalism rejects ideological struggle and stands for unprincipled peace, thus giving rise to a decadent, Philistine attitude and bringing about political degeneration in certain units and individuals in the Party and the revolutionary organizations.

Liberalism manifests itself in various ways.

To let things slide for the sake of peace and friendship when a person has clearly gone wrong, and refrain from principled argument because he is an old acquaintance, a fellow townsman, a schoolmate, a close friend, a loved one, an old colleague or old subordinate. Or to touch on the matter lightly instead of going into it thoroughly, so as to keep on good terms. The result is that both the organization and the individual are harmed. This is one type of liberalism.

To indulge in irresponsible criticism in private instead of actively putting forward one's suggestions to the organization. To say nothing to people to their faces but to gossip behind their backs, or to say nothing at a meeting but to gossip afterwards. To show no regard at all for the principles of collective life but to follow one's own inclination. This is a second type.

To let things drift if they do not affect one personally; to say as little as possible while knowing perfectly well what is wrong, to be worldly wise and play safe and seek only to avoid blame. This is a third type.

Not to obey orders but to give pride of place to one's own opinions. To demand special consideration from the organization but to reject its discipline. This is a fourth type.

To indulge in personal attacks, pick quarrels, vent personal spite or seek revenge instead of entering into an argument and struggling against incorrect views for the sake of unity or progress or getting the work done properly. This is a fifth type.

To hear incorrect views without rebutting them and even to hear counter-revolutionary remarks without reporting them, but instead to take them calmly as if nothing had happened. This is a sixth type.
1/2
>>788
To be among the masses and fail to conduct propaganda and agitation or speak at meetings or conduct investigations and inquiries among them, and instead to be indifferent to them and show no concern for their well-being, forgetting that one is a Communist and behaving as if one were an ordinary non-Communist. This is a seventh type.

To see someone harming the interests of the masses and yet not feel indignant, or dissuade or stop him or reason with him, but to allow him to continue. This is an eighth type.

To work half-heartedly without a definite plan or direction; to work perfunctorily and muddle along--"So long as one remains a monk, one goes on tolling the bell." This is a ninth type.

To regard oneself as having rendered great service to the revolution, to pride oneself on being a veteran, to disdain minor assignments while being quite unequal to major tasks, to be slipshod in work and slack in study. This is a tenth type.

To be aware of one's own mistakes and yet make no attempt to correct them, taking a liberal attitude towards oneself. This is an eleventh type.

We could name more. But these eleven are the principal types.

They are all manifestations of liberalism.

Liberalism is extremely harmful in a revolutionary collective. It is a corrosive which eats away unity, undermines cohesion, causes apathy and creates dissension. It robs the revolutionary ranks of compact organization and strict discipline, prevents policies from being carried through and alienates the Party organizations from the masses which the Party leads. It is an extremely bad tendency.

Liberalism stems from petty-bourgeois selfishness, it places personal interests first and the interests of the revolution second, and this gives rise to ideological, political and organizational liberalism.

People who are liberals look upon the principles of Marxism as abstract dogma. They approve of Marxism, but are not prepared to practice it or to practice it in full; they are not prepared to replace their liberalism by Marxism. These people have their Marxism, but they have their liberalism as well--they talk Marxism but practice liberalism; they apply Marxism to others but liberalism to themselves. They keep both kinds of goods in stock and find a use for each. This is how the minds of certain people work.

Liberalism is a manifestation of opportunism and conflicts fundamentally with Marxism. It is negative and objectively has the effect of helping the enemy; that is why the enemy welcomes its preservation in our midst. Such being its nature, there should be no place for it in the ranks of the revolution.

We must use Marxism, which is positive in spirit, to overcome liberalism, which is negative. A Communist should have largeness of mind and he should be staunch and active, looking upon the interests of the revolution as his very life and subordinating his personal interests to those of the revolution; always and everywhere he should adhere to principle and wage a tireless struggle against all incorrect ideas and actions, so as to consolidate the collective life of the Party and strengthen the ties between the Party and the masses; he should be more concerned about the Party and the masses than about any private person, and more concerned about others than about himself. Only thus can he be considered a Communist.

All loyal, honest, active and upright Communists must unite to oppose the liberal tendencies shown by certain people among us, and set them on the right path. This is one of the tasks on our ideological front.
2/2
>>775
>Linux kernel is now approaching 28 million lines of poorly documented code, making it completely beyond what a actual audit is capable of assessing, beyond comprehension.
most of that is drivers. the kernel itself is still in the low hundred thousands LOC.
>>790
>most of that is drivers. the kernel itself is still in the low hundred thousands LOC.
It depends on how you draw the line between kernel and the rest, for example should /fs be included? You obviously need more than just /kernel to have something that functions, even excluding drivers. Regardless what we're talking about here is the difference between four orders of magnitude and two too large on the upper and minimum end in comparison with plan9. Additionally changing the figure of the LOC doesn't change the number of CVE's per major version, or the time to resolve them. This is LOC from the kernel in 2015 according to a stack overflow post (cause too lazy):
=============================================
Item Lines %
=============================================
./usr 845 0.0042
./init 5,739 0.0283
./samples 8,758 0.0432
./ipc 8,926 0.0440
./virt 10,701 0.0527
./block 37,845 0.1865
./security 74,844 0.3688
./crypto 90,327 0.4451
./scripts 91,474 0.4507
./lib 109,466 0.5394
./mm 110,035 0.5422
./firmware 129,084 0.6361
./tools 232,123 1.1438
./kernel 246,369 1.2140
./Documentation 569,944 2.8085
./include 715,349 3.5250
./sound 886,892 4.3703
./net 899,167 4.4307
./fs 1,179,220 5.8107
./arch 3,398,176 16.7449
./drivers 11,488,536 56.6110
=============================================
>>788
>>789
This is actually quite nice in terms of a genuine code of conduct rather than the technical principles listed elsewhere in the thread.
>>780
I've been struggling to make a more elegant manifesto form of these principles. Something that has come to my attention is that the main types of security issues I'm talking about here are actually insecurity as a product of lack of understanding, specifically type and memory errors. The other focuses of the security section are perhaps something that would be better stated as a purpose than a method. Likewise with the creation of
purpose and planning. The ideal is not really completeness for its own sake, but to prevent scope creep, and to allow for understanding.

I guess what I'm thinking is that understandability is the most significant criteria for developing good software. It seems that I even think it is more significant than ones goals because goals must be modified to allow for the creation of understandable programs.

What do you think; is understandability the highest measure of quality software?
>>796
how do you measure understandability.

For security you want to have a programming environment that wont let you make progrmas with memory leaks and so on.
>>797
>how do you measure understandability.
I don't think it's easily quantifiable. I gave some of my thoughts on heuristics earlier in the thread though. Basically is this program the simplest possible program capable of achieving its objectives (completeness implied), is it the simplest possible solution given the context of all the other programs you would like to run, is it well documented (literately programmed), is the scope of the project limited to prevent it from becoming too complex, and does the language it is written in promote understanding (protect against type and memory errors etc).

>For security you want to have a programming environment that wont let you make programs with memory leaks and so on.
Of course, I was just commenting that this can also be framed as a understanding issue. Writing a program in a enviroment conducive to memory leaks is the same things as working in a enviroment that's not conducive to understanding the way our program interacts with memory.
>>796
>What do you think; is understandability the highest measure of quality software?
This is a poor representation of what I was thinking looking back, the following is much better: The degree to which a program's source code is as understandable as possible while achieving its objectives, is the degree to which it is quality source code. A addendum to this might emphasize that certain design concessions should be made in favor of understandability of source code to the extent to which these design decisions don't impact the objectives of the program.

I think I was even getting a bit twisted up in my own words because in this new formulation, it seems extremely reasonable, if not common sense. There are many other parts of a program which this maxim does not assign qualitative value to though. Specifically at most its influence on purpose is limited to the division of programs, it has no effect on purpose on a aggregate of programs.
>>811
>The degree to which a program's source code is as understandable as possible while achieving its objectives, is the degree to which it is quality source code.
I think that's a fairly complete, refined principle for programmers. As I mentioned this is no where near a complete philosophy of computing though in that it completely neglects what is a reasonable objective, or set of objectives. I really like the Seven Laws of Sane Personal Computing given here: http://www.loper-os.org/?p=284 but it seems to be missing somethings, for example comments on UI, and can likely be refined more.
>>820
>for example comments on UI
I'm nowhere near refined principles on this topic currently, but I can think of a number of important things when it comes to UI, specifically ergonomics, extendability, and lack of redundancy.

Can you think of any more?
>>829
>Some important things when it comes to UI are ergonomics, extendability, and lack of redundancy.
I think effectively at the moment what this is suggesting is something like the K programming language would be the ideal in terms of UI. Now of course according to the definition of quality source code perhaps K can not be considered a good programming language because it does not maximize this quality of programs written in it (I don't really know K well enough to say this honestly). So maybe another constraint is that the UI has to fulfill whatever purpose it is intended to well. Something else that I thought of is that the UI should really be consistent. Perhaps that means using mnemonics, logograms, rational layout of keys, or using minus instead of underscore for spaces.
In the future there will be trained AI that can take existing codebases and refactor them down to simpler forms for you, adhering to design principles that you have set it to follow. Manual code refactoring is monotonous labor. Life's too short to manually rewrite something like the Linux kernel. Monotonous labor should be handled by faster, smarter machines, not the lowly homo sapien brain.
>>855
>In the future there will be trained AI that can take existing codebases and refactor them down to simpler forms for you, adhering to design principles that you have set it to follow.
I guess if you had complete accuracy in your (dependent) types this would be more possible. Idris can already generate some code based on your dependent types, but it still needs a great deal of user interaction. Regardless, the rules are just as useful for making new software as rewriting old, and honestly I wouldn't promote rewriting Linux (which is just a example) so much as making a new painting.
>>854
>Some important things when it comes to UI are ergonomics, extendability, and lack of redundancy... Maybe another constraint is that the UI has to fulfill whatever purpose it is intended to well. Something else that I thought of is that the UI should really be consistent.
So here's a interesting thought, what if similarly to understandability the principle of good UI was just ergonomics extended to include a sort of "mental ergonomics". One could on this principle alone justify having a consistent system which lacked redundancy and was ergonomic in the traditional sense. More than this extendability would often be a requirement because we often don't have perfect foresight into how our systems would be optimally used, in these cases extension is a crucial mechanic (we could always extend the program ourselves and this should be done so long as the program can be completed). Once again this seems to render a fairly common sense principle, together the rules thusfar are:

>The degree to which a program's source code is as understandable as possible while achieving its objectives, is the degree to which it is quality source code.
>The degree to which a interface is as physically and mentally ergonomic as possible while achieving its objectives, is the degree to which it is quality interface.
>c) unquestioned assumptions (primarily those given to us by unix)
What are these "unquestioned assumptions given to us by unix"?
Should I read "The Unix Hater's Handbook" to know? Would I be better served reading something else?
>>866
>What are these "unquestioned assumptions given to us by unix"? Should I read "The Unix Hater's Handbook" to know? Would I be better served reading something else?
That's a great book, although at this point many of the complaints are outdated you can still see some of the impacts, I'd encourage you to read it. Reading summaries of the Unix philosophy critically after reading https://www.dreamsongs.com/WorseIsBetter.html is also a good introduction.

The most important thing though I think is to just think critically about what Unix supports. Is it actually reasonable to say that every program should serialize and parse its data rather than just passing actual data structures? Is it acceptable that there are no safety measures making things as simple as moving, editing, or deleting a files foot guns? Is it tolerably that programs' source can't be inspected and edited live like in Emacs but rather we have to make forks and separate applications for even the most simple change, if we're lucky we have a cumbersome add-on system opaque to the user. etc.
>>857
I'm struggling to come up with a nice rule, or set of rules for what a good program's objectives should be. It's a much more complex issue that these issues of representation I've dealt with so far. It seems to me the most important semantic rule is that the program's objectives should be in the interest of their user. I can't really think of more than this.

I don't know if I'll leave it at that or not.
>>866
>>873
Here's a list of operating systems with a number of features better and more interesting than UNIX, TempleOS isn't listed here, but other than that seems pretty solid: https://news.ycombinator.com/item?id=10957020
Guess I'll wrap up these principles into a nice toasty CoC:

>Thou shalt operate in the interests of thy users, this is the ultimate commandment. Thy users will not always know what's best for them, so we may disagree with them, but try as we must to serve them.
>Thou shalt make thy user interfaces as physically and mentally ergonomic as possible, while recognizing often we are not capable of making interfaces capable of providing this for every situation, and thusly must allow for customization. When thy hath been forced to trade off between the interests of the users and the interface or artistic direction thy will always side with the users. This is the penultimate commandment all else is tertiary.
>Thou shalt make thy source code including the entire stack as understandable as possible. Certain components likely must be complex to reduce the undesirability of the system over all. Thy shalt always sacrifice undesirability for the sake of the interface and the users, but never for anything else.

Delete
Report

no cookies?