[–]▶ No.873917>>873964 >>874290 >>875008 [Watch Thread][Show All Posts]
>/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code.
>When the Unix Support Group (development organization at Bell Labs) formalized everything, they gave it a long SCCS header, as they did every other file, and then needed to add "exit 0" at the end. The file was therefore infinitely larger than before.
>At some point, somewhere (not sure where) it was decided this was poor engineering, probably because the shell spends time reading that big SCCS header as a comment one byte at a time.
>(It probably became a shell builtin somewhere along the line too, but that's for someone else to study.)
>The command moved to /usr/bin/true. I don't know when, where and especially why.
>Eventually to avoid the unbearable overhead of executing a comment that shouldn't be there at all, someone rewrote true as a C program. What was once an empty file is now a non-portable executable binary compiled from C.
>This is why we can't have good software. This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly.
>But the inexorable forces of improvement dictate we can't accept that, so here we are:
>% file /usr/bin/true
>/usr/bin/true: Mach-O 64-bit executable x86_64
>%
>Instead of:
>% file true
>true: empty
>% true
>% echo $?
>0
>%
▶ No.873918
▶ No.873920
▶ No.873963
▶ No.873964>>873980 >>874041
>>873917 (OP)
>This program could literally have been an empty file, a nothing at all
tbf what couldn't you say this about
▶ No.873980
▶ No.873992>>873996 >>873998
>a name capturing the essence perfectly
Only if you already know what that essence is. Someone not sufficiently adjusted to Unix would be really confused.
GNU true does the right thing. --help flags are the correct solution. Commands ought to be self-documenting.
▶ No.873996>>874021
>>873992
why not a man page instead?
▶ No.873998>>874021 >>874031 >>874418 >>874542
>>873992
#Absolute shit tier
~>> du -h /bin/true
24.5K /bin/true
#Better
~>> du -h /usr/local/sbase/bin/true
8.5K /usr/local/sbase/bin/true
#Best
~>> touch true
~>> du -h true
512 true
▶ No.874006>>874045 >>875414
TRUE(1) User Commands TRUE(1)
NAME
true - do nothing, successfully
SYNOPSIS
true [ignored command line arguments]
true OPTION
DESCRIPTION
Exit with a status code indicating success.
--help display this help and exit
--version
output version information and exit
NOTE: your shell may have its own version of true, which usually supersedes the version
described here. Please refer to your shell's documentation for details about the options it
supports.
AUTHOR
Written by Jim Meyering.
REPORTING BUGS
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Report true translation bugs to <http://translationproject.org/team/>
COPYRIGHT
Copyright © 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to
the extent permitted by law.
SEE ALSO
Full documentation at: <http://www.gnu.org/software/coreutils/true>
or available locally via: info '(coreutils) true invocation'
GNU coreutils 8.26 February 2017 TRUE(1)
▶ No.874007
/* Exit with a status code indicating success.
Copyright (C) 1999-2018 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>. */
#include <config.h>
#include <stdio.h>
#include <sys/types.h>
#include "system.h"
/* Act like "true" by default; false.c overrides this. */
#ifndef EXIT_STATUS
# define EXIT_STATUS EXIT_SUCCESS
#endif
#if EXIT_STATUS == EXIT_SUCCESS
# define PROGRAM_NAME "true"
#else
# define PROGRAM_NAME "false"
#endif
#define AUTHORS proper_name ("Jim Meyering")
void
usage (int status)
{
printf (_("\
Usage: %s [ignored command line arguments]\n\
or: %s OPTION\n\
"),
program_name, program_name);
printf ("%s\n\n",
_(EXIT_STATUS == EXIT_SUCCESS
? N_("Exit with a status code indicating success.")
: N_("Exit with a status code indicating failure.")));
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
printf (USAGE_BUILTIN_WARNING, PROGRAM_NAME);
emit_ancillary_info (PROGRAM_NAME);
exit (status);
}
int
main (int argc, char **argv)
{
/* Recognize --help or --version only if it's the only command-line
argument. */
if (argc == 2)
{
initialize_main (&argc, &argv);
set_program_name (argv[0]);
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
/* Note true(1) will return EXIT_FAILURE in the
edge case where writes fail with GNU specific options. */
atexit (close_stdout);
if (STREQ (argv[1], "--help"))
usage (EXIT_STATUS);
if (STREQ (argv[1], "--version"))
version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
(char *) NULL);
}
return EXIT_STATUS;
}
▶ No.874008>>874011 >>875515
And for a quick comparison:
/* $OpenBSD: true.c,v 1.1 2015/11/11 19:05:28 deraadt Exp $ */
/* Public domain - Theo de Raadt */
int
main(int argc, char *argv[])
{
return (0);
}
▶ No.874011>>874013 >>874023
>>874008
wtf theo, it shouldn't take args.
/* See LICENSE file for copyright and license details. */
int
main(void)
{
return 0;
}
▶ No.874012
▶ No.874013
>>874011
Apparently it can. Weird.
▶ No.874018>>874071 >>874137 >>874566
global _start
_start:
mov eax, 1
mov ebx, 0
int 80h
▶ No.874021>>874059 >>874855
>>873996
It's not portable. Nothing feels better than seeing that glorious EOF block in your Bash scripts. Most utils don't need a gassing-list of headers, for fucks sake I've seen an include list fill my whole 1080p height screen, at 8 font size. It brings a minuscule amount of compiling speed boost (lmao'ing at ur priorities), and a giant fucking dredge for anyone who wants to come in and understand how your code works. Oh, what's this call for getDMoverAndOutNinerNiner()? Let me just search this c file, oh it's only called about 100 times? Well, I'm sure am glad our faithful maintainer decided to use a combined namespace! I'll just look at each match (regex searches make this a bit easier, but not ACCEPTABLE). Well looks like it's not defined here, let me just... jesus christ 30 fucking includes? And they're named dumb shit like "fuckme/daddy.h." Absolutely fucking perfect. Now I need to grep the entire repo for all matches, which thankfully come in at *only* 400 line matches. Let me just repeat the last process, and hope I find it. Fuck. You don't need all of these headers if it's your code. Slam it all into one file and be done with it, so people with productive workflows can zoom around the entire page, instead of having to deal with dumb shit like this. Obj files were a mistake. But back to man pages. Slam your doc under the "--help" case and let it be. The problem with Lameix is that everything spread out into the four corners of the earth. You've got you doc pages, your libs, your includes, your binaries, your configs, all just thrown around everywhere so you need to do some digging in the hope that someone asked the same "where is this one crucial file that doesn't have a standardized location?" Goddamn. I just installed Nginx from source after having to rip out a Ubuntu Nginx package to get a new module. I was shocked and appalled. The entire source was copied into a single directory. /usr/local/nginx. How fucking outrageous is that? All the docs, binaries, confs, and party crackers under one single directory. Even the public_html directory. Who would've thunk it? What madman sacrificed his maintainer status for this? I'll pour one out for you tonight. All of these things can be rectified with proper planning and not being a retard.
>>873998
>sabotagep
A beacon of light in the madness of the /g/.
▶ No.874023>>874032
>>874011
It's code correct, you absolute GNU. Lurk the mailing list.
▶ No.874031>>874038 >>874418 >>874564
>>873998
#Bester
$ touch true
$ du -h true
0 true
▶ No.874032>>874082
>>874023
I was memeing you dip. If you disassemble them they are exactly the same.
▶ No.874038>>874082 >>874101
>>874031
nice. Its due to filesystem right? For example I made that post using a bloated FS (ZFS) whereas if I use something else its 0.
▶ No.874041
>>873964
>an empty file, a nothing at all
Something that is empty and nothing is not the same. The empty set is empty (duh), but it certainly is not nothing (specifically, a set which containst the empty set as an element is non-empty itself).
Also
char *ptr1 = {'\0'};
char *ptr2 = NULL;
ptr1 points to an empty string, ptr2 points to no string at all. They are most certainly very different from one another.
▶ No.874045
>>874006
>do nothing, successfully
>do no thing and do it well
Is that "The UNIX Way"-conformant?
▶ No.874059>>874082
>>874021
You ran the configure script without changing any of the defaults, didn't you?
▶ No.874071
>The command moved to /usr/bin/true. I don't know when, where and especially why.
The why is it isn't needed at boot. /bin/ and /sbin/ have binaries needed to boot up, before /usr/bin/ is mounted. You can for example have /usr/bin/ in a remote filesystem, not so for /bin/. Of course that's not a real use-case, but a different partition is. The whole reason /usr/ exists in the first place is they ran out of space in / half a century ago and solved it by putting binaries in /usr/bin instead.
>>874018
>mov ebx, 0
>not xor ebx, ebx
BLOAT
▶ No.874082>>874100
>>874032
No. Make two files, "you.c" and "bsd.c". Now copy paste each example you gave. Your no args example into the "you.c" file and raadt's example into "bsd.c". Now run
gcc -S -O0 bsd.c & gcc -S -O0 you.c && gcc -O0 -c bsd.s && gcc -O0 -c you.s && gcc bsd.o -O0 -o bsd && gcc you.o -O0 -o you && ls -la | grep -o "you$" | sed "s/.*/(&)/g"
>>874038
No, it's probably your sbase "du" bin. Older ones, iirc, report everything in 512 bytes, so any 0 byte files automatically get reported as 512 bytes. I'm using GNU's du, so it reports real sizes. Echo a nullbyte into "true" and then run du again. Tell me if it changes.
>>874059
Yee. I saw the path options, but skipped over them. A welcome surprise.
▶ No.874100>>874105
>>874082
>
gcc -S -O0 bsd.c & gcc -S -O0 you.c && gcc -O0 -c bsd.s && gcc -O0 -c you.s && gcc bsd.o -O0 -o bsd && gcc you.o -O0 -o you && ls -la | grep -o "you$" | sed "s/.*/(&)/g"
Ironically your (you) broke because sbase's grep doesn't support '-o' but I get the point. I should have disabled compiler optimizations before embarrassing myself.
▶ No.874101>>874159 >>877079
>>874038
Aw fuck, I'm a retard. It's likely because du only shows physical sizes, and ZFS allocates everything in 512 chunks instead of just a listing, like ext3. Do ls -sh "FILE" if you want the logical "real" size. And then do stat "FILE" if you want more info on how ZFS does shit compared to ext3. If you do, post a blank file and a one-ascii file for me. I need to quench my autism.
▶ No.874105>>874121
>>874100
If you have a neurotypical version of sed, I can whip up a "portable" version.
▶ No.874121>>874138
>>874105
No need, I made something absolutely disgusting myself.
ls | sed '/^bsd/d;s:\..*::;s:.*:(&):'
▶ No.874137
▶ No.874138>>874159
>>874121
I was trying to figure out how you got autism, but I realized I had a file in my directory already there.
ls | sed '\:.*....$:d;s:s:a:;s:-.*::;x;'
▶ No.874145>>874159
ls | sed '\:.*....$:d;s:s:a:;s:-.*::;x;s:d:g:;s:b:f:;'
▶ No.874159>>874185
>>874101
~>> touch true; printf '\0' > true.ascii
~>> du -h true*
512 true
512 true.ascii
~>> ls -lh true*
-rw-r--r-- 1 fag fag 0 Feb 23 19:06 true
-rw-r--r-- 1 fag fag 1 Feb 23 19:06 true.ascii
~>> stat true*
File: true
Size: 0 Blocks: 1 IO Block: 131072 regular empty file
Birth: -
File: true.ascii
Size: 1 Blocks: 1 IO Block: 512 regular file
Device: 23h/35d Inode: 27383 Links: 1
~>> stat -f true*
File: "true"
ID: 1fb6b072003a5d31 Namelen: 255 Type: zfs
Block size: 131072 Fundamental block size: 131072
Blocks: Total: 943915 Free: 930326 Available: 930326
Inodes: Total: 238189294 Free: 238163584
File: "true.ascii"
ID: 1fb6b072003a5d31 Namelen: 255 Type: zfs
Block size: 131072 Fundamental block size: 131072
Blocks: Total: 943915 Free: 930326 Available: 930326
Inodes: Total: 238189294 Free: 238163584
>>874138
>>874145
My power level isn't high enough for hold space yet.
▶ No.874185
>>874159
>stat -f
What did he intend to convey, when he decided to post this code snippet in our Forum of Fastidious FOSS Followers, Fanatics, and Fetishists?
▶ No.874197
Yeah, Unix sucks, shells suck, standards bodies suck, GNU sucks -- this isn't news buddy. If I were to start scrutinizing everything about my system I'd end up wasting half my life implementing my own Right Thing user space on top of Linux.
▶ No.874206>>874214 >>874216
GNU true being bloated trash and me being able to make a shorter code in assembly is pretty much what I've been saying for a year, but you just called me a faggot.
▶ No.874214
>>874206
Thats because you are a faggot. If you read the rest of the post you would have realized that part of the problem with it being a C executable is that it is not portable which is the exact same case for assembly. The best solution is an empty file named true.
▶ No.874216>>874219
▶ No.874219>>874229 >>874237
>>874216
What an amazing world we live in where I have to carefully select what hardware I buy in order to run any of the Unix operating systems presently on the market.
▶ No.874229>>874306
>>874219
I've run Linux, FreeBSD, and OpenBSD on arbitrary commodity hardware for a long time and it mostly works fine to great. You can of course choose to buy stuff without drivers but a random spin of the wheel in the desktop / laptop segment is going to almost always be fully supported.
Regardless this isn't an argument for writing Unix utilities in assembly, that's been done multiple times and always petered out or dead ended.
▶ No.874237
>>874219
Wouldn't it be wonderful if software didn't have to support hardware! There would be no need for operating systems like Unix! No need for drivers!
▶ No.874290>>874291
>>873917 (OP)
literally who????
▶ No.874291>>874302 >>874332 >>874615 >>875055
>>874290
Rob Pike was one of the inventors of plan9, go and utf-8.
He is one of the few remaining unix wizards, corrupted by google but hey, is what it is.
▶ No.874302>>874321 >>874333
>>874291
>unix wizard
you mean sour grapes spergs who can't into Multics or Lisp Machines? They're brainlets, not wizards.
▶ No.874306>>874313 >>874535
>>874229
Survivor's bias. Now try Illumos or Linux-libre.
▶ No.874313>>874347
>>874306
I'm not a fan of Unix, but I think this particular problem is because hardware is terrible, not because Unix is bad at being portable.
▶ No.874321
>>874302
>sour grapes
You're dumb.
▶ No.874332>>874333 >>874370 >>874536 >>874615 >>875415
>>874291
So who are the wizards of the current generation?
>inb4 Poettering
lel no
▶ No.874333>>874357
>>874302
>be Rob Pike
>pioneer principles of OS design that is used in the most dominant OS on the planet
>develop the most used text format on the planet
>develop one of the top 10 worlds most popular language
>powers Google's backend
>co-authored books with Brian Kernighan
Oh I bet he is just seething over not sticking to multics and lisp
>>874332
Define current generation.
▶ No.874347>>874359
>>874313
unix dindu nuffin
▶ No.874355>>874356
>complaining about the runtime performance of a command that is almost guaranteed to be a shell builtin in any non shit shell from the last ten years
Have we reached peak retardation yet, /g/?
▶ No.874356>>874358
>>874355
>Rob Pike
>shell built-ins
bloat
▶ No.874357>>874540
>>874333
>Define current generation.
People between about 20-25 and 45-50 years old. Folks like Ken Thompson, Brian Kernighan, Rob Pike, RMS, ESR, the dudes who made C++, Java, Perl, Python etc. are all beyond that. Linus Torvalds can just barely still be called "current generation", but not for much longer.
▶ No.874358>>874360
>>874356
>he wants things like cd and pwd to be separate binaries
▶ No.874359
>>874347
>dindu nuffin and did it well
▶ No.874360>>874615
>>874358
I'm sure he wants pwd to be a separate binary.
But cd can't be a separate binary, unless you go back to the days when fork() didn't exist. Nobody wants that.
▶ No.874370>>874445
>>874332
Nobody really. Either counterproductive cucks like Poettering or just soyboys and pajeets all the way down.
▶ No.874372>>874418
du -h /bin/true
28K /bin/true
w-why...
▶ No.874418>>874419 >>874424
>>874372
>>874031
>>873998
>du -h
eh I think you mean du -b.
▶ No.874419>>874424
>>874418
I think you mean du -bh. Or du -b | numfmt --to=si if you want to be all modular but nevertheless use GNU.
▶ No.874421>>875679
who cares it's not like that extra jpeg worth of space has value
electron baBYYYYYYYY
▶ No.874424>>874427
>>874418
Actually I might be wrong here I just checked on busybox and I don't see a way to get du to report file size.
So I guess what we really want is
stat -c %s
Which bugs out my shell where it's stat -c "%s"
or you could just use ls -lh.
>>874419
Yeah -bh. --to=si is a different measure.
▶ No.874427>>874446 >>875114
>>874424
--to=si is a more correct measure. 10³ is human-adapted, 2¹⁰ is just silly.
▶ No.874445
>>874370
So, in the end, computing *was* a mistake after all.
▶ No.874446>>874449
>>874427
Are you a HDD maker? They also think that powers of 2 are silly
▶ No.874449>>874450 >>874474
>>874446
Powers of two are mostly used in practice for signalling you know things about compooters
▶ No.874450>>874456
>>874449
Just like using numbers over 5 is signalling for you dun went 2 skool.
▶ No.874456>>874466
>>874450
Powers of two shouldn't be mixed with decimal notation. If you use decimal, use SI prefixes. If you use a binary prefix, use hexadecimal or something, not decimal.
▶ No.874458
▶ No.874466>>874468
>>874456
>Hey tony I've got 5.5M over here
>wtf does that even mean
>Hey tony I've got 5.7M over here
>ah so clear
▶ No.874468>>874478
>>874466
5,700,000 B should equal 5.7 MB, not 6 MB. Converting between units is easy when they match your notation.
▶ No.874474>>874476
>>874449
If you don't know why powers of two are more usuful when dealing with binary-based computers (i.e. basically all of them), then I'm not sure why you're here. You think the hexadecimal number system (which is just shorthand for binary, four binary symbols are contracted to just one hexadecimal symbol) is also arbitrary and inferior to decimal in all contexts?
▶ No.874476>>874479
>>874474
I meant that using powers of two for information units is usually signalling. Obviously there are lots of places in general where powers of two are desirable.
Hexadecimal is superior to decimal in a lot of contexts. But in contexts where you're already using decimal, like ordinary not-super-technical human communication, proper SI prefixes are almost always the way to go.
▶ No.874478>>874482
>>874468
5.44 MiB is preferred though.
By the way the "1.44 MB" floppy disk capacity is wrong. A standard high density floppy disk has a capacity of 1,474,560 B (512 B per sector * 18 sectors per track * 2 tracks per cylinder * 80 cylinders per disk), which makes it either 1.47 MB (1474560/(10^3)^2), or 1.41 MiB (1474560/(2^10)^2). The "1.44 MB" is a figure popularized by diletants who combined a base-2 and base-10 approach.
▶ No.874479>>874482
>>874476
As far as storage is concerned, base-2 is basically always better. Base-10 is used when dealing with bitrate and generally transfer speeds where the base unit is a bit rather than a byte (for instance you usually would use kilo- or megabits etc. which are 1000 and 1,000,000 bits respectively, rather than kibi- or mebibits which would be 1024 and 1048,574 bits respectively).
▶ No.874482
>>874478
My post should have said 5.44 MB instead of 6 MB, sorry.
5.44 MiB is a step up from 5.44 MB, because it's unambiguous, but it's still pretty bad because it's hard to convert. Going from 5,700,000 B to 5.7 MB is trivial, going from 5,700,000 B to 5.44 MiB is tedious, especially if you have to do it manually.
>>874479
Most use of storage units happens at a high enough level that base-2 has no advantages over base-10.
▶ No.874488>>874497 >>874539
~/ $ as true.s -o true.o
.text
.global _start
_start:
movl $1, %eax
movl $0, %ebx
int $0x80
~/ $ ld -T link.ld -o true
OUTPUT_FORMAT("elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SECTIONS
{
. = 0x400000;
.text : { *(.text) }
}
best I can do, still need to strip the section headers.
▶ No.874491
int
truecmd(int argc, char **argv)
{
return 0;
}
▶ No.874497>>874539
>>874488
>bloat
~/tmp% cat test.lst
1 %line 1+1 test.asm
2 [bits 64]
3
4 true:
5 00000000 31C0 xor eax, eax
6 00000002 FFC0 inc eax
7 00000004 31DB xor ebx, ebx
8 00000006 CD80 int 0x80
9
10 00000008 31C0 xor eax, eax
11 0000000A B001 mov al, byte 1
12 0000000C 31DB xor ebx, ebx
13 0000000E CD80 int 0x80
14
15 00000010 B801000000 mov eax, 1
16 00000015 31DB xor ebx, ebx
17 00000017 CD80 int 0x80
18
19 00000019 B801000000 mov eax, 1
20 0000001E BB00000000 mov ebx, 0
21 00000023 CD80 int 0x80
~/tmp%
▶ No.874535
>>874306
<h-haha you've been successful at running Free OS's on your commodity hardware because driver support has been good for many years, eh pleb?
<well try these obscure operating systems, they don't support much hardware, haha!
Here's your (you).
▶ No.874536
>>874332
Terry, Theo, that's about it.
▶ No.874539>>874547
>>874488
>brainlet couldn't even read the thread before wasting his time
>>874497
You too dumbo
▶ No.874540
▶ No.874542>>874579
>>873998
$ du -h /usr/bin/true
2.0K /usr/bin/true
Better then better but not best :-/
TRUE(1) General Commands Manual TRUE(1)
NAME
true - return true value
SYNOPSIS
true
DESCRIPTION
The true utility always returns with exit code zero.
SEE ALSO
csh(1), false(1), sh(1)
STANDARDS
The true utility conforms to IEEE Std 1003.2-1992 ("POSIX.2").
NetBSD 8.0_BETA June 27, 1991 NetBSD 8.0_BETA
▶ No.874544
I compiled dash with and without the true built-in. The difference in the binary is 104 bytes.
▶ No.874547>>874571 >>874593 >>874620 >>874671
>>874539
original content pls do not steal.
BITS 32
org 0x00010000
db 0x7F, "ELF" ; e_ident
dd 1 ; p_type
dd 0 ; p_offset
dd $$ ; p_vaddr
dw 2 ; e_type ; p_paddr
dw 3 ; e_machine
dd _start ; e_version ; p_filesz
dd _start ; e_entry ; p_memsz
dd 4 ; e_phoff ; p_flags
_start:
mov bl, 42 ; e_shoff ; p_align
xor eax, eax
inc eax ; e_flags
int 0x80
db 0
dw 0x34 ; e_ehsize
dw 0x20 ; e_phentsize
db 1 ; e_phnum
; e_shentsize
; e_shnum
; e_shstrndx
filesize equ $ - $$
▶ No.874564
>>874031
Thinking about me?
▶ No.874566>>874575
>>874018
>x86
kill yourself
▶ No.874571>>874626
>>874547
I see that people have been reading the tiny elf page I've been advocating... Nice.
http://www.muppetlabs.com/~breadbox/software/tiny/
▶ No.874575>>874612
>>874566
The network effect and inertia are the only forces keeping the x86 zombie alive at this point. The faster we blow its head off, the more trouble we save ourselves. Those are facts many people, even on /tech/, have yet to understand.
▶ No.874579>>874583
>>874542
My sbase one would have been smaller if
1. It wasn't statically linked
2. It wasn't compiled on gentoo hardened(Hardening features cause massive bloat).
NetBSD's is pretty good though
#! /bin/sh
exit 0
No idea why they are doing this instead of just making an empty file though.
▶ No.874583>>874588 >>874606 >>875055
>>874579
Maybe it's different on NetBSD, but an empty file doesn't work on my Loonix.
$ ls -l true.*
-rwxr-xr-x 1 user user 0 Feb 24 22:24 true.empty
-rwxr-xr-x 1 user user 18 Feb 24 22:25 true.shell
$ cat true.shell
#! /bin/sh
exit 0
$ cat test.c
#include <unistd.h>
int main (int argc, char **argv)
{
execl(argv[1], argv[1]);
}
$ tcc -run test.c ./true.empty; echo $?
255
$ tcc -run test.c ./true.shell; echo $?
0
I think some shells interpret non-executable executables as shell scripts, but true isn't only called from shells.
▶ No.874588>>874599
>>874583
It works for me.
~>> touch true
~>> chmod +x true
~>> ./true
~>> echo $?
0
~>> ls -lh true
-rwxr-xr-x 1 fag fag 0 Feb 24 16:32 true
~>> busybox sh ./true; echo $?
0
~>> cc test.c -o test
~>> ./test ./true; echo $?
0
Thanks for the reminder to install tcc. I had removed it because I was going to write an ebuild for it and then I forgot.
▶ No.874593>>874626
>>874547
I can't decide if you're actually a pajeet or just that embedded systems larper.
▶ No.874599>>875055
>>874588
I made a bit of a mistake, because failing to exec means test.c exits with success, and tcc isn't acting like I expected it to.
Revised:
$ PS1='$? $ '
0 $ cat test.c
#include <stdio.h>
#include <unistd.h>
int main (int argc, char **argv)
{
execl(argv[1], argv[1]);
puts("oh no");
return 1;
}
0 $ tcc -run test.c ./true.shell
0 $ tcc -run test.c ./true.empty
oh no
1 $ tcc test.c -o test
0 $ ./test ./true.shell
oh no
1 $ ./test ./true.empty
oh no
1 $ gcc test.c -o test
0 $ ./test ./true.shell
0 $ ./test ./true.empty
oh no
1 $
Something fucky is going on. I'm not sure what.
▶ No.874606>>874617 >>874656
>>874583
An empty file works on NetBSD. Maybe it's just done that way to keep consistency with 'false'.
$ touch test
$ du -h test
0B test
$ chmod +x test
$ ./test
$ echo $?
0
$ false
$ echo $?
1
$ cat /usr/bin/false
#! /bin/sh
exit 1
$
▶ No.874612
>>874575
you mean the one percent of the one percent doesn't even get it? the world is fucked
▶ No.874615>>874627
>>874291
plan 9 is another shitty variant of *nix not even worth using. utf8 is aids. unicode is aids.
>unix wizard
unix was never good
>>874332
the dudes behind node.js and minecraft :^)
>>874360
pwd shouldn't even be a thing. the command line is some retarded bullshit. things shouldn't revolve around some stupid programs that input and output text that has no defined format and has to be parsed in some idiotic way. that's why plan9's so called superiority and other things that try to slightly improve over *nix are all crap.
▶ No.874617>>874634
>>874606
Are you sure that's not just your shell handling it?
$ ./true.empty; echo $?
0
$ fish
> ./true.empty; echo $status
Failed to execute process './true.empty'. Reason:
exec: Exec format error
The file './true.empty' is marked as an executable but could not be run by the operating system.
125
dash, bash and busybox sh all handle it like a shell script, but fish and my execl wrapper reject it.
▶ No.874620
>>874547
Here's a version with a standards compliant ELF header and that doesn't use the deprecated and extremely slow int 0x80 system call convention
https://github.com/faissaloo/true/blob/master/true.asm
▶ No.874626>>874669
>>874593
It's a manually-built ELF file that embeds the program inside the header, you fucking moron. See >>874571
▶ No.874627
>>874615
>utf8 is aids. unicode is aids.
Kill yourself.
▶ No.874634>>874645
>>874617
>Are you sure that's not just your shell handling it?
I have no idea.
$ fish
Would you like instructions (y or n)? y
This is the traditional children's card game "Go Fish". We each get seven
cards, and the rest of the deck is kept to be drawn from later. The
object of the game is to collect "books", or all of the cards ...
▶ No.874645>>874660
>>874634
Do you have Python?
$ python -c 'import os; os.execv("./true.empty", ["./true.empty"])'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 8] Exec format error
If not, try the C thing.
▶ No.874650>>874652 >>874656
Btw source since no one's actually bothered to go looking
https://twitter.com/rob_pike/status/966896123548872705
▶ No.874652
>>874650
According to some of the replies, if a file is empty it's going to be interpreted by the current interpreter, and that's slow as hell.
▶ No.874656>>874668
>>874650
>please give us your phone number so you can view these tweets
Farewell my sweet cookies, you were of no use
>>874606
tcc -run true.c ./true.shell; echo $?
255
$ tcc -run true.c ./true.empty; echo $?
255
▶ No.874660>>875055
>>874645
>Do you have Python?
I didn't but i just pkgsrc'ed it so i could try this.
$ python3.6 -c 'import os; os.execv("./true.empty", ["./true.empty"])'
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 8] Exec format error
$ du -h true.empty
0B true.empty
$ python3.6 -c 'import os; os.execv("./true.shell", ["./true.shell"])'
$
$ cat true.shell
#! /bin/sh
exit 0
$
▶ No.874668
>>874656
>tcc
tcc looks to be for x86 and arm only?
I am on PowerPC so can't try that sorry.
▶ No.874669>>874670 >>874672
>>874626
>copy pastes other peoples code
>literally no idea how it works
And a poo in a da loo to you too.
▶ No.874670>>874685
>>874669
What is it like from a SO answer/ famous example? Genuinely curious, because I don't feel like stripping the newlines to search it up. Also it's assembly, aren't you bound to get look-a-likes with such simple shit?
▶ No.874671
▶ No.874672>>874674
>>874669
I didn't paste shit, moron. If you want the explanation, go to the link I posted.
▶ No.874674
>>874672
I am not this street shitter, thank you.
▶ No.874679>>874680 >>874696
/bin #Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/sbin #Essential system binaries, e.g., fsck, init, route.
/usr/bin #Non-essential command binaries (not needed in single user mode); for all users.
/usr/sbin #Non-essential system binaries, e.g., daemons for various network-services.
▶ No.874680>>874691 >>874727
>>874679
>Freetards think this is easier than just putting system binaries in C:\Windows and non-essential binaries in C:\Program Files
▶ No.874685>>875522
>>874670
Sure but he made two classic mistakes.
1. posted impressive code
2. the code didn't do what he thought it did
The hallmarks of a true Pajeet.
▶ No.874691>>874721 >>874728
>>874680
>Windowsfags forgot that for some fucking reason there's a C:\\Program Files and a C:\\Program Files (x86)
>like, no shit, of course i'm on x86. Imagine if Unix needed to have /binx86. It's fucking cancer
▶ No.874696>>874753
>>874679
Correct layout is:
/bin
/sbin --> /bin
/usr --> /
#Where /bin is
/bin/${package} --> /opt/${package/bin/${packge_binary}
▶ No.874721>>874727
>>874691
They did this to make things easier for developers using the Win32 API because x86 programs are run under WoW64
Jeffrey Snover, lead developer of PowerShell, probably put the differences between *nix and Windows best when he said;
"...On Linux, everything's an ASCII text file, so anything that can manipulate that is a managing tool. AWK, grep, sed...in Windows, everything's an API that returns structured data..."
In *nix everything is a file and the filesystem doubles as an API. In Windows APIs like the Registry are what set all filesystem variables. The Registry is a binary database. In fact you can have Program Files (x86) point to the regular Program Files dir by editing the Registry
▶ No.874727
>>874680
>Thinking windows is any better.
Lets see, I have found exes in the following
\Windows
\Program Files
\Program Files (x86)
\Users\[user]\appdata - hidden
\Users\[user]\Application Data - hidden
\Users\[user]\Local Data\Application Data - hidden
And that's assuming the program defaults to any recommendation of Microsoft at all, some programs just install to \[program]
The FHS is very far from perfect and carries historical structures from when hard drives were too small to fit the whole system but it's not any worse than Windows.
https://askubuntu.com/questions/130186/what-is-the-rationale-for-the-usr-directory
>>874721
Snover also didn't want the program file split iirc.
Powershell is a great shell for windows because it was made for the registry, you do get some added benefits because of this structure, for instance choosing columns, you can simply get an arbitrary column by choosing the column number, no dealing with delimiter characters or edge cases in your data.
▶ No.874728
>>874691
Some distros do that, but with /usr/lib not /usr/bin because you usually don't have multiple architectures of the same program installed.
▶ No.874753>>874761 >>874768 >>874776 >>874780 >>874783 >>874785 >>875001 >>875005 >>875007 >>879447
>>874696
No. The best layout is:
cd /
ls -la
/boot
/sys
/var
/tmp
You have a bootloader, system-managed files, user-managed files, and a temporary directory that gets wiped on boot.
>root
Why in god's name does root need its own directory? It would be better to lump it under /home (unless it's some wacky zanny filesystem hierarchy shit that won't let you have root under anything but /)
>srv
Almost as useless as /sys. Go look at your /srv dir, and the your /sys dir. Tell me why you think these should be here.
>run
I want potternigger to get his chode out of my aryan goddess Arch. Throw it under proc or back to dev.
>proc
HAHAHA, *wheeze* OH NO NO NO. While I concede the need for a virtual filesystem where we can store all of our Code-Correc(TM) sockets, I have great disdain for needing it in /root. Linus please get your LunexDee kernel under control.
>lost+found
One of the ugliest filesystems out there, but it's important when you're running your webserver on root and accidentally rm -rf / instead of rm -rf .
>lib
Are you, for real? What is your reason for not just sticking it under /usr/lib? It's already symlinked to /usr/lib.
>sbin
>symlinked to /bin/
>/bin/
>symlinked to /usr/bin/
Pull the trigger Pike, do it motherfucker, end me now.
>mnt
Mount all of your data to /tmp.
>etc
There's nowhere to stick this if we follow the *NIX tradition of only having binaries in /usr/bin, but that's retarded. Stick the confs in with the bins so no one has to "find / -name" their way through mismatched filenames for everything. And stick libs with includes. There is absolutely no mismatch here and it consolidates resources.
>dev, home
Is fine, just nest it somewhere else.
>/usr/local, /usr/bin, /usr/local/bin, /usr/local/sbin, /usr/local/etc, /usr/etc/
Whoever started this chain, if you're reading this, reply to this post right now of your mother will die in her sleep tonight. This is the most inane shit ever. There's a logical diverge between system-managed files in /usr/ and non-managed files in /var/. Stick local under var, it's the exact same thing with less goddamn inconsistency and headaches trying to debug fucking retarded package-prefixes. I'm looking at you Fedora, yum+rpm+sometimes install in local+sometimes install in usr+sometimes none of the above.
▶ No.874761>>874774
>>874753
Savage post my dude glad I'm not the only one who thinks the FHS is fucking insane
▶ No.874768>>874774
>>874753
>Merge /etc with /bin
▶ No.874771
Maybe Rob Pike should focus on making his shit-tier language not produce 2MB large binaries for simple hello world programs instead of ranting about 512 Bytes in Unix.
▶ No.874774>>874780
>>874768
After you merge the entire fucking dumping ground that is bin into sensible folders and figure out some sane alternative to single-user mode. There is a trade off though. Bin is really fucking convenient for doing a "/bin/ [TAB COMPLETE]" when trying to find a sys-bin. Alongside would be better. The only reason I suggested merging was because package managers don't even care about how bin works anymore. I already see directories piling up.
>>874761
Not much can be done. Linux is built on so much outdated bloat that can't be ripped out, and it's just going Microsoft-nova and taking no goddamn survivors.
▶ No.874776>>874784
>>874753
I should have explained the layout I posted better. Though most of your post doesn't seem to apply to what I posted.
>/opt/${package} #literally /opt/${package}/{bin,lib,etc,*}
Everything that specific package needs to run is located here. So that we don't have to hack up every single packages build system symlink the contents of lib to /lib. bins contents are symlinked to /bin for usability sake.
>/srv
Where does this even exist? I've never seen it.
>/run
Like you mentioned only exists on pozzed systems.
>>mnt
>Mount all of your data to /tmp.
Sure I guess.
>/dev
It shouldn't be dynamic but it should definitely be there.
>/usr/*
Did you read my first post? Its a symlink to /
The rest of you post seems like lunacy though. I'm talking about a working system here I'm not sure what you are talking about. If I'm wrong and you have a setup like this then please link.
▶ No.874780>>874784
>>874753
>>874774
>etc merged with bin
NO
I can get behind most of what you say though.
permissions and editing rights to bin and etc stuff can really just be done via groups or a sudoers file instead of an entirely new mountpoint.
User profile specific stuff in my opinion should just be like another mini hierarchy, either visible or dotfolders.
Binaries or configs ONLY for user1 should be /home/user1/bin with the conf as /home/user1/etc
Would've saved us from this .local, .config .program-name debacle.
▶ No.874783>>874784
>>874753
>Why in god's name does root need its own directory
Because /home may be on some other partition, perhaps not even on a functional disk, maybe even on a network. If you're going to reinvent Unix, at least try to be smarter than they were.
▶ No.874784
>>874776
It was a semi-related, segue into my mental masturbation. Please do not regard it as a serious reply.
>>874780
Yeah, I love having 50 dotfiles in my home directory, along with a .config directory for miscellaneous configs. Goddman. Emacs also has 3 different possible configs.
>>874783
Heh, try symlinking + bind. You've already beat the devil at his own game, by using his own fiddle as a figging instrument.
▶ No.874785>>874787
>>874753
>/run
>Throw it under proc or back to dev.
>Linus please get your LunexDee kernel under control.
You have no idea what /proc and /dev are, you fucking disgusting moron. Jesus fuck I just can't get over how insanely retarded you are. You dumb fucking nigger. Kill yourself. I almost want systemd to succeed just to spite your dumb ass.
▶ No.874787>>874790
>>874785
Tell me exactly why you think putting run back into dev is a bad thing, without quoting poetry.
▶ No.874790>>874791
>>874787
Because it's not device files you stupid fuck cunt. Stop posting any time.
▶ No.874791>>874794
>>874790
My one request was that you wouldn't quote poettering, and you failed.
▶ No.874794>>874798
>>874791
>/dev
>device files
>special files created with magic things like mknod
Get that through your thick skull, braindead fuck. Don't post your disgustingly shit opinions here ever again.
▶ No.874798>>874800
>>874794
You could even throw them under tmp, it's the best practical solution. There is a stark contrast between what normie autists think is logical and what really is logical: usability. FHS is bloat, systemd is bigger bloat, Poettering setting his goons on the FHS is huge bloat, adding another filesystem because a few people couldn't stand the thought of their peas touching their carrots is the biggest bloat of all. Even me, I am bloat. The best choice for a single-person workstation is to get a choice of how you want your filesystem to be laid out. It doesn't even have to be major, you can just middleman your prefixes, in the hope some retard didn't hardcode a path.
But, the point is, it doesn't matter what the abstract representation of /dev is. After you understand that device nodes and runtime files go there, where runtime files are dot separated, it's not even a problem. The people who are using the system already know where everything goes. The newbies can read the docs and learn how it works. And the root system doesn't keep on becoming more and more out of control. I may have been memeing with a lot of the things there, but this is for real. You are likely autistic if you care about proper labeling in sacrifice of better features. Root-only mounting is a cancer that needs to be excised. Single devs being able to negatively influence people because they have high-functioning autism, is getting a pass from me.
▶ No.874800>>874801
>>874798
>HURRR usability bloat bloat poettering bloat DURR even I am bloat mount points I was memeing only pretending to be retarded
Kill yourself you autistic cancerous fucking faggot.
▶ No.874801>>874817
>>874800
I'm going to bed, aspie. Remember to tuck your weighted blanket under your feet so the cold air doesn't set you off again. And don't forget to tell your mom you appreciate all she's done for you. It's tough raising someone with disabilities, but even through thick and thin, she'll still love you.
Good night.
▶ No.874817
>>874801
Nobody cares brainlet. Just kill yourself already.
▶ No.874855
>>874021
>Oh, what's this call for getDMoverAndOutNinerNiner()? Let me just search this c file, oh it's only called about 100 times? Well, I'm sure am glad our faithful maintainer decided to use a combined namespace! I'll just look at each match (regex searches make this a bit easier, but not ACCEPTABLE). Well looks like it's not defined here, let me just... jesus christ 30 fucking includes? And they're named dumb shit like "fuckme/daddy.h." Absolutely fucking perfect. Now I need to grep the entire repo for all matches, which thankfully come in at *only* 400 line matches. Let me just repeat the last process, and hope I find it. Fuck.
<ctags -R /usr/include src/ include/
<nvim src/gayshit.c
<(move to getDMoverAndOutNinerNiner)
<CTRL-]
That was hard.
▶ No.874866>>875667
Ideally you shouldn't even have a "true" file nor executable lingering on your hard drive taking space. Instead systemd could determine at boot time the actual requirements for a "true" command in the system and generate a virtual command umber /tmp and symlink it under /bin
▶ No.875001
>>874753
>Why in god's name does root need its own directory? It would be better to lump it under /home
Because it's necessary for single-user mode. Home might be a different filesystem and might not even be mounted.
▶ No.875005>>875014
>>874753
>it consolidates resources
But Loonix isn't about consolidating resources. Quite to the contrary, it mandates placing almost every type of resource somewhere else entirely, even if they belong to the same fucking program. That's why you don't have programs in Loonix that have their binaries, libraries, data, configs, docs etc. all in the same directory (like Windows programs often do, especially the portable ones).
▶ No.875007>>875014
>>874753
/ is the primary hierarchy. /usr is the secondary hierarchy (hence /usr/bin, /usr/etc etc.). /usr/local is the tertiary hierarchy (hence /usr/local/bin, /usr/local/etc etc.). What is the issue here?
▶ No.875008
>>873917 (OP)
>MUH CHANGE IS SCAAAAAAAAAAAAAAAAAARRRRRRYYYYYYYYYYYY!!!!!!!!
>FUCK DRUMPF!!!!!!!!!!!!!!!!!!!!!!!!!
▶ No.875014
>>875005
I can think of no sane reason for this, besides using edge cases to justify madness.
>>875007
The main issue here is that that the Lunix filesystem hierarchy is a child of the trough, of all the people that've worked on it, and brought their ego into it. Projects become a disaster when there's more than one person at the helm vying for the "visionary" responsibility. The Lunix filesystem is not the product of careful, deliberate, and single-minded design. It's an abomination of different ideas and compromises, that take away all the benefits of their singular parts. Take the root hierarchy. Poettering's autism won't let him have /run as a sub-directory, fine. I could not care less, but then you have the FHS wanting dedicated media and srv/ points, and then some other idiot decided the meaning of sbin and bin should be context dependent, all of these conflict with Pootering's "everything belongs in their own singular directory." Even look at /var/.*mail. Why? For what reason is this so hard to agree upon. There is a better way to do it, but there are normies standing in the way.
▶ No.875055
>/bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code.
UNIX weenies can't even make a program that does nothing but return 0 work right (not that needing an external executable file to return 0 makes any sense).
>>874583
>>874599
>>874660
This brain damage is, of course, due to praying to
"simplicity of implementation" when implementing switch
and goto, without worrying about "the right thing."
Yes, and they've succeeded. Hordes of grumpy C hackers
are complaining about C++ because it's too close to the
right thing. Sometimes the world can be a frightening
place.
>>874291
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...
▶ No.875114>>875120
>>874427
$ man resize2fs
Note: when kilobytes is used above, I mean *real*, power-of-2 kilobytes, (i.e., 1024 bytes), which some politically correct folks insist should be the stupid-sounding ``kibibytes''. The same holds true for megabytes, also sometimes known as ``mebibytes'', or gigabytes, as the amazingly silly ``gibibytes''. Makes you want to gibber, doesn't it?
Theodore Ts'o has spoken, EOF.
▶ No.875120
▶ No.875414
>>874006
LOL
bash-3.2$ info '(coreutils) true invocation'
info: No menu item '(coreutils) true invocation' in node '(dir)Top'
▶ No.875415>>875431
>>874332
Moldbug's got his own unique brand of autism going, if they can put it into a chip and make it run faster or something it'll be pretty based.
As for now it's just basically autism but it has promise.
▶ No.875431>>875495
>>875415
It's slow because he designed it for a computer that doesn't distinguish between ram and storage, basically he's all in on NVRAM.
I am reading the urbit whitepaper and it's a lot more sane than just getting jargon bombed in the docs.
It also helped me realize why he made these seemingly bizarre decisions, worth the read.
▶ No.875495>>875496
>>875431
>It's slow because he designed it for a computer that doesn't distinguish between ram and storage, basically he's all in on NVRAM.
That was a main Multics and AS/400 feature and it's faster than the file I/O that UNIX uses. Running it on top of UNIX makes it slow.
http://multicians.org/multics-vm.html
>The fundamental advantage of direct addressability is that information copying is no longer mandatory. Since all instructions and data items in the system are processor-addressable, duplication of procedures and data is unnecessary. This means, for example, that core images of programs need not be prepared by loading and binding together copies of procedures before execution; instead, the original procedures may be used directly in a computation. Also, partial copies of data files need not be read, via requests to an I/O system, into core buffers for subsequent use and then returned, by means of another I/O request, to their original locations; instead the central processor executing a computation can directly address just those required data items in the original version of the file. This kind of access to information promises a very attractive reduction in program complexity for the programmer.
>In most existing systems that provide for information sharing, the two requirements mentioned above are not met. For example, in the CTSS system [5], information to be shared is contained in files. In order for several users to access the information recorded in a file, a copy of the desired information is placed in a buffer in each user's core image. This requires an explicit, programmer-controlled I/O request to the file system, at which time the file system checks whether the user has appropriate access to the file. During execution, the user program manipulates this copy and not the file. Any modification or updating is done or the copy and can be reflected in the original file only b an explicit I/O request to the file system, at which time the file system determines whether the user has the right to change the file.
The lesson I just learned is: When developing
with Make on 2 different machines, make sure
their clocks do not differ by more than one
minute.
Raise your hand if you remember when file systems
had version numbers.
Don't. The paranoiac weenies in charge of Unix
proselytizing will shoot you dead. They don't like
people who know the truth.
Heck, I remember when the filesystem was mapped into the
address space! I even re<BANG!>
▶ No.875496>>875500
>>875495
>mapping the files into memory
What is the page cache?
▶ No.875500>>875545 >>875637
>>875496
Something very different, unless I'm missing something.
Mapping a file into memory means that you can manipulate the file contents directly by manipulating the memory, which can be very convenient.
Unix eventually got it in the form of mmap, around 1990, a few decades later.
▶ No.875515>>876914
>>874008
For a quick comparison GNU true is a shitload faster than the OpenBSD one. It's true, look at the benchmarks.
▶ No.875522
>>874685
I copied the original code which returns 42 because its a popular hack people would recognize, or be interesting enough to encourage reading the code before being spoonfed the explanation.
▶ No.875540
▶ No.875545>>875637
>>875500
How to properly handle error conditions with mmap? Since you're editing memory there's no function return value. Signals like SIGSEGV are used, and handling signals is pure hell and even if I do it right and return from the handler I just end up back in the code that caused it.
How the fuck does this work?
▶ No.875637>>875644 >>875660 >>875661
>>875500
>Mapping a file into memory means that you can manipulate the file contents directly by manipulating the memory, which can be very convenient.
>Unix eventually got it in the form of mmap, around 1990, a few decades later.
Like most things in UNIX, mmap is "a childish, vulgar, totally unsatisfying imitation" of the real thing.
>In segmented systems, hardware segmentation can be used to divide a core image into several parts, or segments [10]. Each segment is accessed by the hardware through a segment descriptor containing the segment's attributes. Among these attributes are access rights that the hardware interprets on each program reference to the segment for a specific user. The absolute core location of the beginning of a segment and its length are also attributes interpreted by the hardware at each reference, allowing the segment to be relocated any where in core and to grow and shrink independently of other segments. As a result of hardware checking of access rights, protection of a shared compiler, for example, becomes trivial since the compiler can reside in a segment with only the "execute" attribute, thus permitting users to execute the compiler but not to change it.
>If this address is a "null" address, initialize the block of core with zeros and update the segment length in the ASTE; this action is only taken the first time the page is referenced since the segment was created and provides for the automatic growing of segments. Other wise issue an I/O request to move the page from secondary memory into the free block of core and wait for completion of the request via a call to the "traffic controller" [14] which is responsible for processor multiplexing.
>>875545
>How to properly handle error conditions with mmap? Since you're editing memory there's no function return value. Signals like SIGSEGV are used, and handling signals is pure hell and even if I do it right and return from the handler I just end up back in the code that caused it.
Signals are done right in real operating systems, but they're broken in UNIX. No wonder nobody does error checking.
Unix encourages, by egregious example, the most
irresponsible programming style imaginable. No error
checking. No error messages. No conscience. If a student
here turned in code like that, I'd flunk his ass.
Unix software comes as close to real software as Teenage
Mutant Ninja Turtles comes to the classic Three Musketeers:
a childish, vulgar, totally unsatisfying imitation.
▶ No.875644>>877811
>>875637
TMNT was good nigger needs to stfu
▶ No.875660>>875661 >>877408 >>877410
>>875637
Yeah Unix sucks I know I posted a lot in the kill Unix thread. However its what we got now so answer the goddamn question: how to handle mmap signals properly?
▶ No.875661>>877408 >>877410
>>875660
>>875637
Also I know full well exactly how shitty signals are. You have no idea how much I hate signals. Signals were a mistake. Trying to handle these fucking things is what made me hate Unix in the first place.
The best implementation I got is saying fuck POSIX, blocking fucking everything so my code can't actually be interrupted, using signalfd to epoll signals and handle them in an event loop on a separate process cloned with shared memory just for that exact purpose. I effectively turned my program into a micro-node.js.
Even this monstrous event loop thing breaks down when faced with mmap though, due to the simple fact it can't be captured by signalfd, and even if it could it wouldn't make sense since I'd have no way to figure out where the segmentation violation actually happened. So yeah, it's back to handler functions here.
I was thinking about long jumping away from the handler into exception handling code burt I dunno. I'm confused and don't quite know what I'm doing right now. I need to sleep on it.
▶ No.875667
>>874866
>if a script that uses true has a filename which starts with a digit, systemd true will dump to a root shell
▶ No.875679
>>874421
>one day `true` is going to be an electron app that pops up with the text "true" and a button that says "share to twitter" which your smart-home-thermostat is polling 800 times every nanosecond in order to find out if you're cold or not
▶ No.876914
>>875515
you missed this in the GNU one:
/* Note true(1) will return EXIT_FAILURE in the
edge case where writes fail with GNU specific options. */
The GNU one should be considered infinitely slow because it is not correct.
t. Lamport
▶ No.877079
>>874101
Get yourself a filesystem with tail packing, anon.
▶ No.877358
but rember tthat the length doesn't equal performance
▶ No.877408
>>875660
>>875661
>Also I know full well exactly how shitty signals are. You have no idea how much I hate signals. Signals were a mistake. Trying to handle these fucking things is what made me hate Unix in the first place.
Multics did signals properly and it didn't need mmap because every file was addressable as memory. Almost everything in UNIX is broken or wrong in some way.
>The best implementation I got is saying fuck POSIX, blocking fucking everything so my code can't actually be interrupted, using signalfd to epoll signals and handle them in an event loop on a separate process cloned with shared memory just for that exact purpose. I effectively turned my program into a micro-node.js.
UNIX had the same problems in 1992 and people said UNIX sucked compared to real OSes.
http://multicians.org/mgs.html#signal
>PL/I name for an exception. PL/I signals have continuation semantics; that is, a condition handler can return to the point of the signal. The Multics environment maps hardware events, e.g. zerodivide, linkage fault, out-of-segment-bounds reference, into PL/I signals. When a signal is raised, the runtime searches back up the stack for a condition handler for the signal, and invokes it if found. If no handler can be found, the runtime starts over, looking for a handler for the condition "unclaimed_signal". Each listener on the stack establishes an unclaimed signal handler. If invoked, this handler prints a message and "caps" the stack, establishing a stack frame for a new "command level" by calling a new listener. Issuing the start command to the new listener returns to the signal handler, which returns to the point of error and retries the instruction that faulted.
Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages. How many B*Tree
packages do we NEED? I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas. So why not support certain
common denominators in the OS?
Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy. If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...
▶ No.877410
>>875660
>>875661
>Also I know full well exactly how shitty signals are. You have no idea how much I hate signals. Signals were a mistake. Trying to handle these fucking things is what made me hate Unix in the first place.
Multics did signals properly and it didn't need mmap because every file was addressable as memory. Almost everything in UNIX is broken or wrong in some way.
>The best implementation I got is saying fuck POSIX, blocking fucking everything so my code can't actually be interrupted, using signalfd to epoll signals and handle them in an event loop on a separate process cloned with shared memory just for that exact purpose. I effectively turned my program into a micro-node.js.
UNIX had the same problems in 1992 and people said UNIX sucked compared to real OSes.
http://multicians.org/mgs.html#signal
>PL/I name for an exception. PL/I signals have continuation semantics; that is, a condition handler can return to the point of the signal. The Multics environment maps hardware events, e.g. zerodivide, linkage fault, out-of-segment-bounds reference, into PL/I signals. When a signal is raised, the runtime searches back up the stack for a condition handler for the signal, and invokes it if found. If no handler can be found, the runtime starts over, looking for a handler for the condition "unclaimed_signal". Each listener on the stack establishes an unclaimed signal handler. If invoked, this handler prints a message and "caps" the stack, establishing a stack frame for a new "command level" by calling a new listener. Issuing the start command to the new listener returns to the signal handler, which returns to the point of error and retries the instruction that faulted.
Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages. How many B*Tree
packages do we NEED? I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas. So why not support certain
common denominators in the OS?
Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy. If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...
▶ No.877811>>878856 >>879083
>>875644
Except it was TMHT ("Teenage Mutant HERO Turtles") in Europe, as "ninja" was believed to not be kid-friendly enough.
▶ No.878856
>>877811
I live in Europe.
▶ No.878871>>878880 >>878881 >>878886 >>878911
Benchmarks (measured with `time for i in {1..1000}; do ./foo; done`):
<Bash's `true`>
Unknown size, 2 µs
<Empty Bash file>
0 bytes, 4.765 ms
<`exit 0` Bash file>
7 bytes, 4.533 ms
<AMD64 assembly linked with -s>
352 bytes, 4.061 ms
<C compiled with -O3 -s>
6,128 bytes, 4.277 ms
<GNU true compiled through Portage with -O2 in CFLAGS, invoked as `/bin/true`>
31,644 bytes, 4.552 ms
<Ada compiled with -O3 -s>
476,184 bytes, 4.360 ms
<Go>
1,034,959 bytes, 4.418 ms
>mfw even Go is faster than GNU's garbage
▶ No.878880>>878909
>>878871
>fast code is always better
t.codelet
▶ No.878881>>879079
>>878871
>this absolute garbage benchmark
>convincing anyone of anything
▶ No.878886>>879150
>>878871
For me C vs asm shows a much bigger difference (like half the time). I think the asm you used is shit, fasm gets it in 129bytes:
format ELF64 executable 3
segment readable executable
entry $
xor edi,edi
mov eax,60
syscall
Not that it matters since if true is your bottleneck you're doing something wrong.
▶ No.878909>>879458
>>878880
Yes. Yes it is. Fast code is OBJECTIVELY better than slow code. Always.
▶ No.878911
>>878871
There is no meaning in this kind of benchmark because there is no meaning of true beyond the truth of true.
▶ No.879079
>>878881
Seemed ok to me. Next time use ministat.
▶ No.879083>>879086 >>879453
>>877811
>in Europe
Did you know that Europe is not a single state or culture or society and that "in Europe" usually means "in 1-3 countries"
▶ No.879086
▶ No.879150
>>878886
>I think the asm you used is shit
Of course it is. It's GNU's as.
▶ No.879387
▶ No.879447>>879457
>>874753
/sys and /proc are filesystem interfaces to the kernel. Keeping them in / away from any other path that might get written to by mistake is a Good Thing.
▶ No.879453
>>879083
Did you know Europe is a Union of "countries" and when most people say "In Europe" they typically use it as shorthand for "The European Union"? Not to mention the bureaucrats in charge want the "United States of Europe" to be a thing
▶ No.879457
>>879447
/sys is a filesystem interface to bricking your computer.
▶ No.879458
>>878909
Are you a GCC developer?
>>868312