IRC channel logs
2021-11-07.log
back to list of logs
<oriansj>but I always hope for people like me to show up and actually make some real progress. <oriansj>oh and I almost forget the government is now so out of touch with reality, that IT9 positions (you know the entry level IT jobs that are the basis of Government hiring/staffing funnels) now offers less than McDonalds does to people making french fries. <muurkha>part of the problem is that security is invisible, so management can't measure it, so it can't set it as a target <muurkha>it's not invisible to everyone, of course <oriansj>well it isn't invisible, it just got turned into a set of checkboxes that tend to often depend on buying products. <muurkha>but it requires certain knowledge to see it, similar to environmental pollution <muurkha>the checkboxes are visible, but they aren't security <muurkha>people who can't see security are limited to setting the checkboxes as an objective <oriansj>but easily mistaken for it and drains what funds existed for actual security <muurkha>people who *can* see security often don't have power <oriansj>short term efficiency metrics are the basis of the economy and planning cycles <muurkha>when people who can't see security have power, they don't have it for long <muurkha>like when people who can't see profitability have money <muurkha>France's Maginot Line held for more than a decade, but don't underestimate Amazon <muurkha>if an Amazon system is insecure, it's probably because Amazon aren't the ones who lose money when it gets penetrated <oriansj>well any business that can lose billions for more than a decade, isn't one to be ignored <oriansj>selling entire categories of product below cost to starve out competition in multiple markets <muurkha>I think the PCRAM folks went 20 years before turning a profit <oriansj>and DEC made a profit in its first quarter <muurkha>Ovonyx was founded in 01999, was acquired by Micron in 02012, and I don't think ever made a profit in that whole time <oriansj>yet here we are, DEC is gone (because it was more profitable to kill than keep alive) and Amazon is trying to take over the world <muurkha>DEC died partly from patent suits but mostly because of a series of spectacularly bad decisions in the 01980s <oriansj>MOS went deep into debt trying to sell the 6502; only to be bought by one of their customers who refused to pay their bills (Commadore) <oriansj>SuperVAX and the death of PRISM being the two big ones I think <muurkha>I don't know about PRISM, but I was going to say the cancellation of the -10 line, the focus on VMS, and completely flubbing the PC market <muurkha>I mean DEC had personal computers sitting on hundreds of thousands of desktops by 01980 in the form of the VT-100, which had a more advanced version of the same CPU as Datapoint, Altair, Cromemco, IMSAI, and Osborne were using <oriansj>well PRISM was their thrust to take the workstation market with VAX compatibility, but instead they went MIPS and ULTRIX which completely broke all compatibility <oriansj>only for PRISM to become an underground project in DEC and re-emerge as DEC ALPHA <muurkha>when they finally tried to enter the PC market in 01982 it was with the DEC Rainbow, which was gratuitously IBM-incompatible <muurkha>yeah, the Alpha could have been fabulous <oriansj>but the lack of byte instructions were a serious mistake they fortunately corrected <muurkha>but it was kind of their last chance, and so the patent suits sunk them <oriansj>bad luck determines the fate of more businesses than talent does <muurkha>01984 was the wrong time to launch a new ECL product. 01982 was the wrong time to launch a new IBM-incompatible PC. 01977 was the wrong time to launch a new proprietary (Unix-incompatible) operating system. in 01978 they wasted expensive 8085s on implementing shitty ANSI escape sequences instead of, like, local text editing or something actually useful <oriansj>Having smart people on staff doesn't mean they will have the good luck of building the right thing that the market wants <muurkha>when they discontinued the -10 line in 01983, both CompuServe and much of the internet were running on -10s. I FTPed files from a -10 at spacelink.gsfc.nasa.gov in 01994, and wsmr-simtel20.army.mil, one of the greatest libraries of software in the world, was also a -10 until it was shut down by a copyright lawsuit in 01993 <oriansj>and even if you do; having the good luck that management doesn't try to kill it (See Xerox) <muurkha>DEC's terrible decisions go back even further; Dirty Genitals was born in 01968 because Edson de Castro couldn't convince DEC's management to follow up the PDP-8 with a 16-bit machine <muurkha>but DEC was still in great health, even though they could have *owned* DG's market, until the 01980s <oriansj>I guess that is the greatest strength of our community, bad luck doesn't kill a path of progress; just delays it until the next person is willing to take a swing at it. <muurkha>but I think they were suffering from a really pathological lack of imagination from at least the late 01970s, and it finally killed them <muurkha>well, that was true then; it may not be true now <muurkha>(when I said Datapoint and Altair used the same CPU it was sort of a lie. Datapoint's CPU was the one the 8008 was a clone of) <muurkha>well, consider what the CPU landscape looked like in 01982. DEC had the -10, the PDP-11, the VAX, and some lingering PDP-8 business. Motorola had introduced the 68000 three years earlier, provoking National to bring the much prettier and on-paper-competitive NS32000 to market in 01982. Berkeley RISC got their first silicon, with 68000-like performance with enormously fewer transistors <muurkha>Cray was selling the Cray-1, the first computer to make the promise of vector instructions really come true. IBM was still pushing the S/370, HP had several different lines of computers (the 16-bit HP-2100, the 16/32-bit HP-3000, I forget what else), Tandem had their fault-tolerant 16-bit minicomputer clusters, and of course in the PC market the 6502 and 8080 8-bit machines were giving way to the <muurkha>there were literally dozens of viable architectures from over a dozen companies: Datapoint, HP, IBM, DEC, Burroughs, Intel, National, Motorola, DG, AMD, Tandem, Commodore (already the owner of MOS), Zilog (which already had the Z8000), Univac, CDC, Honeywell, NCR, Amdahl, Cray, etc. <muurkha>Now what do we have? in terms of designs, outside the microcontroller realm, we have ARM, AMD, their cloner Intel, RISC-V (MIPS has finally given up), IBM, and maybe Apple <muurkha>but all of these are locked in patent cross-licensing deals with each other <muurkha>except RISC-V, which avoided it by intentionally designing a CPU architecture to be as uninnovative and boring as possible <muurkha>worse, though, there are only two companies capable of *manufacturing* cutting-edge chips: Samsung and TSMC. not even Intel has been able to keep up, though maybe they'll make a comeback <muurkha>to have the opportunity to take advantage of TSMC's or Samsung's cutting-edge processes, you need several million dollars and an NDA <muurkha>and if you try to do anything interesting, like Alpha, you'll surely be destroyed by the patent lawsuits, as DEC was <muurkha>oh, I forgot to mention NVIDIA, and of course both AMD and Intel have their own GPU architectures as well <muurkha>the death of Moore's Law has taken most of the potential revolutions off the table <oriansj>honestly, I was going to do something retro; knight in metal <muurkha>this is not a recipe for robustness in the face of failures; this is a recipe for stagnation <muurkha>cool! you know what I think of Knight though :) <oriansj>the revolutions come not from the direction where all the eyes stare but in the back where no one thinks anything can be done. <muurkha>maybe, but you know what? most of the time revolutions don't come, because the established order succeeds in preventing them. that's how it's been for most of human history <muurkha>this concentration of manufacturing power and this thicket of patents give the established order veto power over innovation. expect them to use it <stikonas>hmm, goto is often discouraged in C, but for some things in M2-Planet it's the simplest way <stikonas>hmm, although, I think in this case I can replace it with do ... while() loop <stikonas>well, do ... while() loop is just goto under the good anyway <muurkha>do-while is more readable when it's the right solution <stikonas>yeah, I ended up using do_while there... <stikonas>so declaration of multi-dimensional global static arrays is now working, but not yet using them... <stikonas>declaration is just calculating correct size to reserve <oriansj>well right now multi-dimensional arrays don't quite work right <stikonas>well, yes, that's what I'm trying to look into <stikonas>so far I only got it to correctly reserve the size <stikonas>there was also a problem in that other function that I fixed <stikonas>but just on its own that fix is not useful <stikonas>well, something for the future to think about <stikonas>well, it's more complicated than what I can do in 15 min.... <oriansj>that reminds me; I need to fuzz the new preprocessor functionality <stikonas>yeah, that part is not formally tested yet <stikonas>would be good to have some simple tests to test stuff like #ifdef, #ifndef, #if VARIABLE, #unset <stikonas>GCC actually is fairly clever even at -O0 <stikonas>it keeps track of array sizes and just emits required offset <muurkha>it has to keep track of array sizes in any case in order to be able to allocate static or auto arrays <stikonas>hmm, actually I think you have to keep track of array sizes... <muurkha>or put them into structs as a non-last item, or answer sizeof() queries <oriansj>woo, looks like M2-Planet is growing a new set of brains again <oriansj>slowly M2-Planet is tracking more state and information <stikonas>well, I don't know yet how multi-dimentional array loading will look like... <stikonas>or maybe even somebody else will get it working before me <stikonas>but hopefully it's not super complicated to do <oriansj>and looks like I've found some segfaulting test cases <oriansj>ok cleared out some segfaults and gonna let it fuzz overnight. <Irvise>On Integrating Racket with GNU Mes <stikonas[m]>mes is actually not as tied to Guix as that video implies <stikonas>oh, I think I've got multi-dimensional arrays working <stikonas>in addition to that one commit yesterday that fixes initialization <stikonas>hmm, maybe actually a bit more work is required... <oriansj>stikonas: has Sage actually shown up here yet? <oriansj>So incorrect bootstrap info wouldn't be surprising. <stikonas>oriansj: in general multi-dimensional arrays seem a bit tricky, I still don't know how to implement everything. But I did manage to get special case of char ** working (the one from known_issues file) <stikonas>I don't think either mes or tcc use multi-dimensional int arrays <oriansj>well it also doesn't pass existing tests <oriansj>it happens; but if I were to guess the addition to postfix_expr_array is the problem <stikonas>maybe need to guard it additionally on nex token being '[' <Hagfish>it's always satisfying when tests find an actual implementation problem (as too often people write tests which break after a refactor even if the functionality hasn't changed) <oriansj>stikonas: just a thought but isn't just match("[", global_token->s) correct as one shouldn't be doing thing[][] on anything that isn't ** or more **...* <oriansj>as then it'll also work for SCM**, long** and int** and unsigned** <stikonas>nevertheless, static arrays like int[2][3] wouldn't work, but that's expected <stikonas>since I didn't implement any flattening of those multi-dimensional arrays <oriansj>umm multi-dimensional arrays aren't flat but array of pointers to arrays <oriansj>remember we only need source code compatibility; not implementation <oriansj>aka does foo[a][b] = c; behave the same way <stikonas>but yes, that thing is implementation specific <oriansj>foo[a] being a pointer to an array _ and _[b] is the thing we need to set <stikonas>still, then we need to add code to create those pointers <oriansj>yeah, merging just the second will be fine. <stikonas>creating array of pointers would need different code <stikonas>it might be less efficient than flattened arrays but definitely easier to implement in M2-Planet <stikonas>ok, let me rebase PR to have just 2nd commit <oriansj>we could also change out the array logic to do flat arrays if we wanted to make M2-Planet more efficient. <stikonas>anyway, for now I updated PR with just that 2nd commit <stikonas>mescc-tools-extra/cp actually already used argv[i][j] code <stikonas>oriansj: one thing that might need updating is known_issues file <stikonas>I'm building with ./bin/M2-Planet --architecture riscv64 --debug -f M2libc/sys/types.h -f M2libc/stddef.h -f M2libc/riscv64/Linux/fcntl.h -f M2libc/riscv64/Linux/unistd.h -f M2libc/stdlib.c -f M2libc/stdio.c -f M2libc/bootstrappable.c -f b.c -o b.M1 && ../riscv64/bin/blood-elf --64 --little-endian -f b.M1 -o b-footer.M1 && ../riscv64/bin/M1 --little-endian --architecture riscv64 -f M2libc/riscv64/riscv64_defs.M1 -f M2libc/ <stikonas>riscv64/libc-full.M1 -f b.M1 -f b-footer.^C -o b.hex2 && ../riscv64/bin/hex2 --little-endian --architecture riscv64 --base-address 0x600000 -f M2libc/riscv64/ELF-riscv64-debug.hex2 -f b.hex2 -o <stikonas>maybe it works on risc-v but not on amd64... <stikonas>oriansj: are you sure you are building with new M2-Planet? <oriansj>yeah, it looks like I forgot the ./bin/ before M2-Planet and it was using my local installed copy. <oriansj>you are correct that it is in fact working and I should convert it to a proper test