/g/ - Technology

I've read about it in a sci-fi novel and thought it looked cool. Around the same time I got my hand on a Pentium II computer and some guy gave me a copy of a Red Hat 5.1 CD. I also found a dial-up modem but without the floppy disk with the drivers for Windows 98.
Linux just worked. I also wanted to learn C and there was already everything I needed in the Linux disks, no need to pirate Borland.

>>233
Which year are you talking abou? and what novel btw.

>>241
1997 and I think I have installed Red Hat 5.0 first. It was freshly released when my friend handed me the CDs. I got 5.1 later from a magazine.
The book was The Revolution of the Ants by Bernard Werber. Linux is mentioned somewhere. It's a good book when you're a kid

couldnt afford windowz

>>153
this.

>>158
Write your own.

>>144
Use vichan, honestly. Lynxchan is better on a technical level but:

>ugly as sin by default
>developed by a dick
>not as feature rich

>>160
no offense but that's bad advice

These days there are more imageboards than imageboard users.

>>239
It's a good thing. Instead of having blogs with comments, people run anonymous imageboards.

>>226
>Is the format even the same for CPython, PyPy and other Python interpreters? Sorry for the questions, I have no idea how it works.
https://docs.python.org/3/glossary.html#term-bytecode
"""Python source code is compiled into bytecode, the internal representation of a Python program in the CPython interpreter. The bytecode is also cached in .pyc files so that executing the same file is faster the second time (recompilation from source to bytecode can be avoided). This “intermediate language” is said to run on a virtual machine that executes the machine code corresponding to each bytecode. Do note that bytecodes are not expected to work between different Python virtual machines, nor to be stable between Python releases.

A list of bytecode instructions can be found in the documentation for the dis module."""

https://docs.python.org/3/library/dis.html
"""The dis module supports the analysis of CPython bytecode by disassembling it. The CPython bytecode which this module takes as an input is defined in the file Include/opcode.h and used by the compiler and the interpreter.

CPython implementation detail: Bytecode is an implementation detail of the CPython interpreter. No guarantees are made that bytecode will not be added, removed, or changed between versions of Python. Use of this module should not be considered to work across Python VMs or Python releases."""

>I was hoping for something more detailed
https://github.com/python/cpython/blob/3.8/Python/compile.c

>>227
Looks like I just need to RTFM. Do they somewhere also explain why they decided to keep the bytecode implementation defined?

>>228
I'm not aware of a direct statement of the rationale behind that decision – it's not in e.g. the Design and History FAQ [0]. The spirit of The Python Language Reference suggests that it was specified in terms of an abstract execution model [1] precisely to allow more freedom for Alternate Implementations [2].

[0] https://docs.python.org/3/faq/design.html
[1] https://docs.python.org/3/reference/executionmodel.html
[2] https://docs.python.org/3/reference/introduction.html#alternate-implementations

>>224
When running a python program, the following steps are taken:
Python source code -> abstract syntax tree (AST) -> bytecode
Hy replaces the "Python source code -> AST" step.

We should note that bytecode is an implementation detail.
CPython has its own format, Jython compiles to JRE bytecode, and other implementations can use more complicated means such as running and compiling simultaneously (JIT compilation).


>>226
>Maybe they do it like this because there's no portable bytecode format?
It's simpler if you just replace the "source code -> AST" step.
AST is the ideal model to compile your code to
because it is the same level of abstraction as it's input (source code).
You can easily see create and run your own AST with python's ast library.
It's pretty trivial to even implement a simple language yourself using that library.

>>234
Doesn't it make a lot of optimizations impossible to do? Since you are basically translating your semantics into sugar-free Python.

I'm really sorry about textboard.org but Bitdiddle said the stress tests were badly needed and kept encouraging me. I hope it's back up soon.

>>216
It seems to have returned from death.

…

Why are you testing in production?

>>217
>Why are you testing in production?
Setting up a local copy is such a hassle and Bitdiddle said:

>Don't worry about that. I'm sincerely grateful you found that severe bug, took the time to read the code and offered a way to fix the issue

>We badly need those. Now is the time.

>Thank you again for discovering that awful bug. I believe your stress tests will hit the nginx cache, so they should be safe.

I am trying to change a pretty fundamental type in a functional program, as the current one turned out to be inadequate… Hopefully I won't end up having to rewrite the whole thing. How do functional programmers deal with cases like this? Just get it right before beginning?

>>230
Looks like I managed to avoid the situation. Though I am still curious how people deal with situations like that.

>>194
>facebook
Not even if every imageboard died.

>>195
Agreed. I would rather lurk archived threads

>>209
If you have archived threads, the option for ghostposting exists.

>>178
Lain is fine. I feel like there isn't enough space for shitposting. You are just overreacting.

>>222
lainchan decline era user detected

Yeah boys. some of my (free || open) source software

1. OSs: Debian, Void, Plan9, & OpenBSD
2. Editors: Acme, Emacs, & Sam

W8.
Here is a list:
https://github.com/mayfrost/guides/blob/master/ALTERNATIVES.md

>>212
I wish I could find a cute gf that's into free software, a good OS, and hates smartphones.

I am really glad that Anki exists. It saved me from failing out of university.

Try asking on textboard.org maybe.

>>207
Is my thread not welcome here?

I believe this to be very important in today's climate where every megacorporation tries to paint themselves to be great supporters of "open source" and many of our organizations are funded by their "generous donations". But the problem is that they don't give a shit about software freedom. Take Visual Studio Code for example. Microsoft used to advertise it as being Open Source, and millions in good faith downloaded binaries of it. Until a careful eye noticed that the source code released as "Visual Studio Code" was different from the binaries released as "Visual Studio Code". In fact, the binaries even have their own license agreement that you have to accept to use them. After being called out on it, Microsoft modified their website and now Visual Studio Code only claims that it was "built on Open Source", as if that was something to be proud of. But the damage has already been done. I think Docker employed (or still employs) similar tricks. The problem is, pushover (so-called "permissive") licenses do not protect you from this trickery at all. With copyleft licenses, the source code of the binary has to be provided. But with pushover licenses, corporations can put some crippled version of their software on Github as bait, and distribute proprietary versions of it in binary form. This is why I think verifying source-to-binary correspondence, enabled by bootstrappable and reproducible builds, is so important.

>>135
ouchhh. that hurts

similar thing happened to me yesterday on my debian system, i accidentally* removed libc6 and couldn't reinstall it because both apt and dpkg need it

*completely ignored the warnings

I used to regularly thrash my HDD by distrohopping and overwriting it with a new OS every 1-2 weeks. HDD promptly died after a year or 2 and I've now installed Fedora on a SSD and just stuck with it. Distrohopping is a meme :C

I had most trouble with PSUs popping.

>>199
>I used to regularly thrash my HDD by distrohopping and overwriting it with a new OS every 1-2 weeks.
How does that work? A distro install isn't a lot of data, so one every week can't add much to your average write rate.

>>203
I never bothered with thumb drives much, usually because I didn't have one around most times, so I had a separate partition on the disk that I wrote the ISO to which I would boot from. From there I would install whichever distro to the rest of the disk. I basically was writing 3 separate copies of the distro iso/files to the same disk every time I hopped.