| Welcome, Guest |
Welcome to Makestation! We are a creative arts/indie discussion community — Your center for creative arts discussion, unleashed!
Please note that you must log in to participate in discussions on the forum. If you do not have an account, you can create one here. We hope you enjoy the forum!
|
|
|
Spammer here
|
|
|
|
Spammer here
|
|
|
|
Spammer here
|
|
|
|
Spammer here
|
|
|
|
Spammer here
|
|
View all updates
|
| Online Users |
There are currently 354 online users.
» 0 Member(s) | 352 Guest(s)
Applebot, Google
|
|
|
| New Here |
|
Posted by: axe - December 22nd, 2019 at 7:55 PM - Forum: Introductions
- Replies (3)
|
 |
Hi everyone, i'm new here and very excited to join this forum. My friend Guardian recommended checking out this place and it looks very interesting so far
|
|
|
| Hello |
|
Posted by: NealCaffrey - December 22nd, 2019 at 6:17 PM - Forum: Introductions
- Replies (3)
|
|
Hello my name is NealCaffrey.
Found this forum because a friend of mine told me about it.
|
|
|
|
| This Land is My Land |
|
Posted by: Guardian - November 28th, 2019 at 4:50 PM - Forum: Other Games
- Replies (8)
|
 |
So, I bought this early access game on Steam, and I can't stop playing it. It's still got bugs, and still needs some work, but its already a masterpiece:
Quote:Experience the frontier as a chief of a Native American tribe and resist the onset of the settlers. Explore the vast world full of hostile humans and animals while defining your narrative through the decisions you make. Survive, hunt, craft, unite and lead the tribes to take back your lands.
Steam page: https://store.steampowered.com/app/10696...s_My_Land/
Every playthrough is different, as the game world is procedurally generated and even the name you choose comes with different benefits or struggles.
|
|
|
|
| Dev Software |
|
Posted by: Lain - November 7th, 2019 at 3:59 PM - Forum: Software
- Replies (8)
|
 |
I'm considering wiping my PC yet again and I can usually get down my 'essential' software within a few minutes. After that, I focus on getting all my dev shit down and sorted nicely.
So what are your usual editors/toolchains/IDEs that you install whenever building back up?
Windows:
Text Editor:
IDE(s):- CLion (C/C++)
- GoLand (Go)
- IntelliJ (Java)
- Visual Studio (.Net, some C/C++ related stuff too.)
- Arduino (Arduino)
- Keil uVision (microvision) (Embedded applications in C, MDK)
- Gnat/GPS (Ada)
Other:- STM32cubeMX (Code generator for STM32 boards)
- Fritzing (Schematics)
- Choco/NuGet (Package Managers)
- Git
Toolchains:- Node
- MinGW (C/C++)
- Non-VB/C# VisualStudio packages (F#, linux, etc.)
Linux:
Text Editors:- VS Code
- nvim
- Atom (ONLY if VS Code isn't supported on the target without overlays, AKA Gentoo)
IDEs:- Arduino
- mBed (not installed, just what I use.)
Other:
Toolchains:
Most of my Linux development is in C so I don't need to go overboard with the IDEs (not that there are many good ones available for Linux.)
|
|
|
|
| NandGame |
|
Posted by: Lain - November 5th, 2019 at 3:46 AM - Forum: Technology & Hardware
- Replies (8)
|
|
I found a cool game a while ago in some /g/ thread about building a CPU straight from scratch called NandGame.
Link: http://nandgame.com/
You might have learned about some of this stuff in a uni-level computer architecture course, and probably know about lots of the actual gates from either programming or high-school level logic/engineering classes. In any case, the game's pretty fun, I'm currently on the memory section trying to figure out the flip flop (even though I'm familiar with the concept already).
It focuses a lot on NAND (not-and, or inv-and) because, realistically, NAND gates are the cheapest (and sometimes the smallest) to make in fact, that in modern CPU architectures primarily just use NAND gates to build other logic systems. As such, it's theoretically possible to build everything in-game with just NAND gates.
But that would just clutter your screen, so you can use parts that you've already made to build other parts, until you start working your way up to more complex parts where you might be only given your primitive logic gates to complete a level, and in those cases, I've found myself just building those solutions with NAND/NOT gates.
Give it a shot, it's pretty fun and you'll learn lots about how computers work at a hardware level.
|
|
|
|
| Bit Fields for Dummies |
|
Posted by: Lain - November 4th, 2019 at 11:04 PM - Forum: Software
- No Replies
|
|
I recently completed an online course on embedded applications using C.
To tell you the truth, it wasn't worth the few hours I invested in it. I more or less scanned through all the material, and most of it was intro stuff I already knew about optimization, like bit masking using logical/bitwise operators, compiler optimizations, const vs. #define, etc. Nothing particularly difficult to understand as long as you have a good foundation in computer science, ie. understanding how a CPU actually works.
But there was one thing that I did learn, and have wondered about before.
Take some data structure for example. Using C pseudocode, we can assume something that looks like this:
Code: struct {
//some code
}myBools;
And inside that data structure, you've got a bunch of boolean values (ie. true/false)
Code: struct {
bool var1;
bool var2;
bool var3;
bool var4;
bool var5;
bool var6;
bool var7;
bool var8;
}myBools;
Well, note how in this specific use-case, I have eight values in this one structure. Now, Boolean values are either 0 or 1 traditionally, so how large is this data structure?
Well, 0/1 imply bits, so you might think 8 bits, or one byte.
Wrong.
In C, by default, a boolean value takes up one byte minimum, and since most other primitive data types (ie. int, double/float, char, etc.) can also be larger than one byte, we can say that the size can be much greater.
So the data structure given above isn't one byte, but it's eight bytes.
Now, this distresses me. If they're bools, they should only technically be 0 or 1 (or 0 and not 0) so we should be able to cut program size costs from an extra eight bytes to a single byte if we were to modify/read individual bit values.
And sure enough, you can mask/read/write bit values pretty easily, if you used a macro function like this:
Code: #define MASK(x) (1<<x)
int main(){
const char toRead = 0b01001100; //Some 1 byte value defined in binary
uint_8 readVal; //Whatever the value of what we read will be, one byte in size
//read a single byte from a character value
readVal = (toRead >> 3) & MASK(3);
//returns 1
//toggle a single bit:
toRead ^= MASK(3);
//returns 0b01000100
//to set a bit (back)
toRead |= MASK(3);
//returns back to 0b01001100
return 0;
}
But as you can see, using macro functions everywhere can start to make things really unclear, especially when you start to combine them.
Instead, in this course, they covered a cool concept called a 'bit field' which does exactly this, but without the messy code.
Let's go back to our first struct of bools. Instead, we'll rewrite it:
Code: struct {
uint_8 var1 : 1;
uint_8 var2 : 1;
uint_8 var3 : 1;
uint_8 var4 : 1;
uint_8 var5 : 1;
uint_8 var6 : 1;
uint_8 var7 : 1;
uint_8 var8 : 1;
}myBools;
So the format is slightly familiar yet still different.
Code: type Name : bitSize;
Realistically, any type can be used here, but I'm using single-byte ints for the sake of looking cool. What's important is the colon and size of the value in bits. Yes, you can have more than one, say three bits, and so when that field is read, you may have a value from 0-7 (or a three-bit value, 2^3)
Now, we can take another step further. What if you want to set/read a single bit rather than a specified group that you already made in the struct?
Well, you mush them all together. To do that, we use a union (or a structure that is split up and shares memory.)
Code: union{
uint_8 full;
struct{
uint_8 bit0 : 1;
uint_8 bit1 : 1;
uint_8 bit2 : 1;
uint_8 bit3 : 1;
uint_8 bit4 : 1;
uint_8 bit5 : 1;
uint_8 bit6 : 1;
uint_8 bit7 : 1;
}bits;
struct{
uint_8 bit0 : 3;
uint_8 bit1 : 2;
uint_8 bit2 : 1;
uint_8 bit3 : 1;
uint_8 bit4 : 1;
}fields;
}bitField;
//Examples
int main(){
bitField a = 0b01001100; //Same number as above.
uint_8 readVal;
//To read a single byte
readVal = a.bits.bit3;
//returns 1
//To read the first three bits in the field:
readVal = a.fields.bit0;
//Returns 4
//To set a bit:
a.bits.bit3 = 0;
//To toggle a bit:
a.bits.bit3 ^= 1;
//To read the value of the whole byte:
readVal = a.full;
//returns 0b01001100, or 76, or 0x4C
return 0;
}
So in short, that's how you turn a structure of eight bytes into a structure of eight bits instead, without making the code completely unreadable.
It feels a little more object oriented this way, but overall, it's pretty well optimized.
|
|
|
|
| A little more RE |
|
Posted by: Lain - October 25th, 2019 at 7:33 PM - Forum: Software
- Replies (4)
|
|
I've been holding onto a file for almost a decade now. To be exact, very late 2010, maybe early 2011. We're soon approaching a full nine years, and I've been holding onto this file essentially since I was a dumb kid in the hopes that one day I'll be able to do something with it.
The file doesn't even technically work. It's a trainer for Call of Duty: Black Ops which was made shortly after the game came out (only allegedly worked for Campaign/Solo zombies) and was shortly patched thereafter. Sure, it looked sort of cool, design-wise:
![[Image: 1f0f862259d53fadca7c9eb0b674aaa8.png]](https://i.gyazo.com/1f0f862259d53fadca7c9eb0b674aaa8.png)
But otherwise, it was patched, and thus, did not even work.
I kept this file throughout the years for one reason alone: to figure out how to extract the music file.
I cannot find this version of the song anywhere online, since lots of demoscene music generally is pretty obscure (think of late 90s/early 00s chiptune in trainers/keygens) and even the song itself is relatively obscure: The NeverEnding Story by Limahl (the theme to the movie.)
So over the years, as I'd learn more about programming or general computer science, I'd think of ways that maybe I could use something to help me figure out how to take this program apart, and hopefully something will finally make the dent I needed.
Now, LinGon is long gone, can't find any new handle and his social media/old accounts haven't been touched since like 2013 at latest. So asking him for help would have been out of the question.
The file in question is here, for anyone's will to follow along with the process:
Code: [url=http://www.mediafire.com/file/1yhgkz6u7r61c4c/CODBO%252B11Trainer-LinGon.exe/file]http://www.mediafire.com/file/1yhgkz6u7r61c4c/CODBO%252B11Trainer-LinGon.exe/file[/url]
Before you ever run a program on your computer, especially something that can be considered a hack tool, you should scan it with VirusTotal or something. For me, as a hobbyist, I've found that tons of samples will come back infected despite being clean because of strange function calls, and that it's also incredibly easy to make a sample that doesn't get detected. Weird world, so instead of trusting the results of a bunch of AVs, I use HybridAnalysis to get clues about what the program does, then I make the decision of actually running/debugging the program myself.
At the time of playing CoD:BO, I was running Windows 7 in those days, and I only had 4GB of RAM so I figured using the 32bit options on HA would be fine to test. After all, I'm not looking for detections, I'm looking for clues.
![[Image: ec81fcfd874435088221e4f95a624917.png]](https://i.gyazo.com/ec81fcfd874435088221e4f95a624917.png)
Unfortunately, HA thinks the file is malicious:
https://www.hybrid-analysis.com/sample/7...8042042fcc
Why?
Because allegedly it reads 'terminal service related keys'
And apparently RDP programs do that.
You know what else does that?
Trainers (and game-hacking tools.)
Why?
Because you need to get around anticheat somehow, buddy.
This was the only mainly concerning aspect of the analysis done, and it's easily explained. There's no web-traffic or any networking whatsoever (it doesn't even import the necessary networking libraries) so it's unlikely anything malicious is going on.
There were a few things that stood out to me from the analysis though:
Code: Written/Compiled with VisualBasic 6.0
Packed with PECompact
Barely any discernable strings (reinforces the packed idea)
Strange API imports (likely due to the packing)
No files extracted
VisualBasic means that maybe we can do some dotnet RE which would make life easier.
PECompact gives us at least the name of what we're looking for when we want to unpack it.
No files means that the resources section of the file is also packed. I was hoping to maybe get an MP3 from this, but I suppose not.
Since it's allegedly written in VB6, we should try to decompile to VB6 (even if it's undiscernable initially,) so I plugged the file into dotPeek, a free .Net decompiler. It works on .exes, .dlls, or any binary for that matter as long as it's written in a .NET language, like VB.
![[Image: 0bc1d942a3874607eceb361ca308977f.png]](https://i.gyazo.com/0bc1d942a3874607eceb361ca308977f.png)
No go.
Guess not.
So now, we need to bring out the big guns. A real debugger, since although it's importing all the .Net stuff, it's hidden so there's probably lots of native code surrounding it.
Enter x64dbg (or x32dbg in my case.)
x64dbg (known as xdbg from here-on-in) is essentially the spiritual successor to the world-famous OllyDBG, except that Olly has way less features and doesn't work for 64bit binaries, making it a little too useless in the modern-day. xdbg also supports 32bit binaries, and is entirely free, making it a great choice for us right now.
So I downloaded the binaries, started up x32dbg (the 32bit version obviously,) and plugged in the Trainer file I've been saving for today.
![[Image: db463ba19d642e76d94d979a194cc42a.png]](https://i.gyazo.com/db463ba19d642e76d94d979a194cc42a.png)
And it seems to work fine. It hits a system breakpoint and stops execution, allowing me to start poking around.
First, to understand most packing schemes, there's very little you need to know. Most packing/obfuscation schemes operate sort of similar to this pseudo-ASM code:
Code: 0x401000 ---- jmp 0x601000 ;entry point of the binary, jumps to arbitrary location, assume this instruction is 5 bytes
0x401005 ---- ;garbled nonsense spanning the majority of the file
....
....
0x601000 ---- call decryptGarbled ;decryption function for the above garbled mess
0x601004 ---- add ebp,5 ;adjust execution stack pointer by 5 bytes, ie. makes 0x401000 into 0x401005, changing the base
0x601010 ---- jmp [0x0] ;starts execution from where the garbled was, now decrypted code.
So realistically, we just need to follow the trail.
First, in xdbg, we need to find that entry point for the program (currently the breakpoint is highlighted, also in a different section than the program itself, so we need to poke around more. The logs show us something interesting:
![[Image: 40a9a0a007799c1f3232ee8355967e20.png]](https://i.gyazo.com/40a9a0a007799c1f3232ee8355967e20.png)
And there it is, also neatly hyperlinked for our convenience!
Clicking it starts off our journey:
![[Image: 50638429cf8b9831728a73218a813a06.png]](https://i.gyazo.com/50638429cf8b9831728a73218a813a06.png)
And just our luck, there's a new address being pushed into the accumulator.
First, I'll assemble that one instruction and note it down in case I need the value later:
Let's see where that takes us:
![[Image: 0d92e39018722baa3b921cb4c5b332bf.png]](https://i.gyazo.com/0d92e39018722baa3b921cb4c5b332bf.png)
So this time, an integer (32bit) is being pushed into the accumulator. Nothing really to follow here, especially when there's a ret instruction shortly after, so we need to actually think back to the explanation I gave earlier of how packers work.
They jump around, decrypt, then jump around again. It looks like the accumulator is also being used as 'storage' for where the instruction pointer should jump around to, so let's see what returns when I search for:
![[Image: c0501a1d2a5b9f7164a1128ede560eb8.png]](https://i.gyazo.com/c0501a1d2a5b9f7164a1128ede560eb8.png)
![[Image: 6f301682502925c912054dcee67ce359.png]](https://i.gyazo.com/6f301682502925c912054dcee67ce359.png)
Two results only. That narrows it down quite a bit.
Now let's go back to our noted down asm instruction:
mov eax, 0x8E42B0
0x8E42B0 is much bigger than 0x8DFB5B, so that probably won't be it.
Instead, I'll attach a breakpoint to the second option, since it does come after where we just were.
And now, all that's left to do is hit the 'Run' button at the top.
You see, although we're in this weird disassembly mode, we're not trying to get a disassembled raw source; we're looking for the original source. At some point in this program's execution, that original source will be visible, even for an instant, because the program needs to decrypt it first then start execution. So we let the program handle the heavy-lifting and reap the rewards, hence we just start running it.
So hit run/step a few times until we get to the jmp eax instruction. What you'll notice is that in the comment beside (that x64dbg generates on its own,) is that eax = the original EntryPoint we had, just as I predicted.
![[Image: 20028fffa11510533536a6b1158b49ab.png]](https://i.gyazo.com/20028fffa11510533536a6b1158b49ab.png)
Now, just take one more (single-instruction) step to get to the real Entry Point of the application:
![[Image: a9df71761ad67e3cfea3ce94e92a24a1.png]](https://i.gyazo.com/a9df71761ad67e3cfea3ce94e92a24a1.png)
And now, we actually recognize a few things on the screen. There are actual function names, for a start. This is the real packed program. Now all that's left to do is dump it.
So we open the Scylla toolkit. Keep 'Attach to Active Process' selected, since it's what we're debugging. And since Scylla has some decent automation, we just hit IAT Autosearch.
IAT means the import address table, ie. all the libraries and whatnot that are being imported.
Then, smash 'Get Imports'
![[Image: 94087bb6374caf8311a0cf7b3f8a92c7.png]](https://i.gyazo.com/94087bb6374caf8311a0cf7b3f8a92c7.png)
Okay, there are errors. For whatever reason, whatever we dump probably won't run properly.
f*** it, the trainer was already broken. I'm looking to extract a resource, not fixing the f*** code.
Hit dump, save the file, and get out of there, since we're done with the debugger.
That was the worst of it. Now we have a few options:
--Since the file was packed, it didn't open in dotPeek. The resources were also hidden in ResourceHacker.
--I can binwalk/search for file headers with a hex editor.
First I tried dotPeek:
![[Image: dfc2640065b551b230818bd5405ef509.png]](https://i.gyazo.com/dfc2640065b551b230818bd5405ef509.png)
Two in a row. One more failure and I get a hat trick.
Next, ResourceHacker:
![[Image: 696c0467f91f8966851e5e9da9596b62.png]](https://i.gyazo.com/696c0467f91f8966851e5e9da9596b62.png)
I noticed that there are a couple of WAVE (.wav) files there, a total of five. There are also some custom files, but they don't seem to dump properly with reshacker, so that's a no-go.
When looking through a file to find different types of files, we need to look for file signatures, ie. magic numbers. It's usually the first four to eight bytes which define what a filetype is and how to open it. Funnily enough, the .zip magic numbers are used for almost everything, but that's a story for another time.
When searching WikiPedia's list of file signatures, I found .wav:
The 4 dots represent a 32bit integer for the size of the file.
I know there are five of these files embedded in the .exe. So let's pop it into my favourite Windows hex editor, HxD, and try to find these headers:
![[Image: 3734acf453e9dafa9dc0d840329d80a0.png]](https://i.gyazo.com/3734acf453e9dafa9dc0d840329d80a0.png)
Okay, the first one is at 0x3D4AE0. I highlighted the four bytes between RIFF and WAVE which represent the file size. On the right-side, I highlighted the int32 number: 147494
And from 0x3D4AE0 to 0x3D4AE0+dec(147494), I copied and pasted the data into a new file, saved it as Untitled.wav and played it in WinAMP.
And you know what I got?
A f*** Windows Vista error/info sound.
The developer of this trainer used them as the sound effects for turning cheats on/off, or as extra sounds.
And every single .wav file was like this.
Almost defeated, on the last .wav file, as I was selecting the block for the file size, I saw something:
![[Image: 9a4c24df1247e29556a16cf9eeff99c8.png]](https://i.gyazo.com/9a4c24df1247e29556a16cf9eeff99c8.png)
And I was f*** ecstatic. Honestly I still am, it's been almost nine f*** years.
After a quick google search, I found that Extended Module refers to a demoscene file format, .xm, which was popular back in the day of music trackers (what came before FL Studio.)
And after another search, I found a download of FastTracker, the one used to make this track:
https://www.pouet.net/prod.php?which=13350
So I downloaded it and got the .exe
And it only runs on MSDOS, it's that old.
Nothing an emulator can't fix, but that means more setup.
There was another file included, XM.txt
And just my luck: it was the entire documentation of the .xm file format, like all its file header information and how the data is structured.
God bless the demoscene, absolute madmen.
So after reviewing the docs and putting everything together, I finally extracted the full file from the unpacked .exe.
And I was going to go find a program that plays .xm files, but I realized that WinAMP has that support built-in, so I don't even need to reconfigure.
Absolutely amazing.
And now I'm going to convert this to a .wav or .flac and keep it safe for the rest of my life so I never need to go through that process again.
Here's the download link:
http://www.mediafire.com/file/zmy7kor1ko...ry.xm/file
It'll play natively in WinAMP, as mentioned. Not sure about other programs, but you can also install xmp (google it) as an alternative.
Maybe you won't like the song as much as I do. To be honest, it's lost a bit of its lustre, but it still held that sentimental value of playing Black Ops with the boys back in middle school, and that's a d*** good feeling.
|
|
|
|
| What is the most toxic job you've ever had? |
|
Posted by: Darth-Apple - October 24th, 2019 at 9:40 PM - Forum: General Discussion
- Replies (1)
|
 |
For me, it was a restaurant that I worked at for quite a while. I put in plenty of grit and gave that place as much energy as I had to give. I finally had had enough and quit. And once I quit, I realized I had my life back...
I was a line person, generally was the lead person on the weekends. That involved being in charge of basic things on the line, and I was the point of contact for anything that happened. Whether something needed to be remade, or a mistake was made, or an order was changed, or we were being too slow, I was the one that heard about it. I was the one who delegated the work, and more or less ran the line and opened the kitchen on the weekends.
I trained many people over the years on that job, and almost always got great reviews from my trainees. Another store opened up, and I trained several of the people who ended up opening the new store (INCLUDING the manager of that store, who ended up transferring and soon managed me.) So yes, I quite literally trained my own manager. I felt my performance was good, but I will explain why I ultimately left.
- It was an incredibly clique-ish environment. There were two primary cliques, and a few smaller ones in the mix.
- The cliques usually hated each other, and passionately so. If you were in one clique, the other one hated you.
- There was a manager that was very involved in the gossip and drama, and usually instigated it. This manager pretty much knew everything there was to know about anyone who worked there. If it happened, he'd know about it, and he'd gossip about it.
- The work parties were a BIG, BIG deal. You had to be in the in-group to be invited. If you weren't invited, you would generally not get hours at work or otherwise be treated poorly. Usually a manger would attend these parties, and would occasionally snitch on people they didn't like to the gm.
- Managers would make sexual jokes about female people on the job. If the guys on the line didn't join in, they were called many derogatory things. Usually they were called gay, whether they were or not, and yes, this was meant in a derogatory way. (Offensive, as there were people who were gay on the job, and should not have to be around having the term used in a derogatory way)
- If you were a relatively nice person, you were instantly a target. Neither group would really accept you. One group would tolerate you, but gossip about you behind your back. The other group would pretty much blatantly refuse to talk to you.
- If you were disliked by someone, they'd usually make up anything about you. People would believe it quickly. You'd be accused of cheating on your significant other (without any merit whatsoever), or of coming into work under the influence, or of other horrible things. Usually these were completely false, but people believed it regardless.
- Speaking of which, if someone was excluded by your clique and you talked to them, even to say hi, and interacted with them in any meaningful way, you would generally be pressured to stop. If you didn't, you'd be excluded yourself.
- One of the managers was very close friends with a couple of people in particular on the line. These people had their heads high in the air, and would be very entitled in general. If they wanted to date you and you didn't like them back, there went your hours. Because this manager was the scheduling manager, and would make sure you were retaliated against.
- The hours, speaking of which, were all over the place. They would promise you 30, give it to you one week, and then cut you to 15 the next week for no reason. Often you were scheduled against your availability. If you got a second job, they purposefully scheduled you against your availability, and would write you up if you called out for your other job.
- If the manager heard some gossip about you and wanted to retaliate, he'd completely remove you from the schedule after you were scheduled and give the hours to someone else. This actually happened, multiple times!
- I was the head person on the line for the weekends. The weakday line lead was extremely mean. I was far, far more liked than she was, and she was generally jealous if anyone was likeable. I had many, many people come up to me and thank me for being far more approachable, unlike her. She went and tried to tell the manager I was bad at my job and tried to get me fired for it.
- Anyone who quit would be fair game for gossip. And it'd be rather extreme. Generally, if you quit, you were not rehireable, no matter what. Many people would unfriend you on social media, and pretty much everyone would stop talking to you.
- It was basically a cult. They were convinced they were the best job ever, and that you were never going to find anything better. If you disagreed with them, they'd put pressure on you by excluding you. You were almost always passionately hated by at least three or four people in the store, all of whom would work vehemently to damage your reputation.
- I quit. Luckily, I was not unfriended by the entire staff. I did, however, unfriend the managers. I still talk to a few people, but by and large, I'm glad to be gone.
I used to sell cars. Even the sales floor wasn't as bad as the restaurant described above.
What's your most toxic work experience? Looking forward to seeing your guys' responses. I'm sure there will be some good ones.
|
|
|
|
| General linux thread |
|
Posted by: SpookyZalost - October 23rd, 2019 at 7:01 PM - Forum: Software
- Replies (13)
|
 |
so I know there's a bunch of dedicated linux threads but I wanted a general one for general linux discussion.
so for anything relating to linux that doesn't have or need it's own thread, like usage, setups, etc, general discussion on the topic.
so what do you guys run as a nix box? and what are your thoughts/experiences with it?
|
|
|
|
|
