What are some of the must-dos, must-installs, must-uninstalls, and must-alters of setting up a new PC? I'm getting my first new PC in 5 years on Sunday and the old one is really showing its age. I would like to avoid that as much as possible in order to keep the PC running smoothly as long as possible. I'd also like to optimize its performance and have useful software tools.

Thank you for any advice,
gbbb

Between the recent discussions on the Useful Shell Scripts thread, and some of the tangents on the Desktop Usability thread, I thought it might be an interesting idea to have a desktop screenshot sharing / unixporn thread where we talk about our setups, preferred applications, and share some pointers. This doesn't specifically have to be a Unix circlejerk though. If you have a Windows/Android/ChromeOS/TempleOS setup with some novel innovations, you're more than welcome to share too.

Oops, just noticed I didn't post this week! My mistake.

What have you been listening to this week? You don't need to do a 6000 word review if you don't want to, but please write something!

Feel free to give recs or discuss anything about each others' listening habits.

You can make a chart if you use last.fm:

http://www.tapmusic.net/lastfm/

Remember that linking directly to your image will update with your future listening, make sure to reupload to somewhere like imgur if you'd like it to remain what you have at the time of posting.

Since Tildes participants generally come from nations with legal systems based on English common law or otherwise requiring jury trial for criminal cases, I'm curious what, if any, experience others have had of serving on juries, trying cases before a jury, or facing a jury as a defendant.

I was unable to participate as fully in this discussion as I would have liked, as I was called to jury service on a child molestation case this week. I'm deeply saddened to say that it was the second time I've served as a juror for judgment on an accused child sex abuser.

That case is now concluded, we returned a guilty verdict today, and I'm at liberty to discuss it if questions arise.

One of the startling things about this case was the huge jury pool called - sixty people, of whom only 8 were seated (6 jurors and two alternates, and we weren't informed as to who the alternates were). The dismaying detail was that of those sixty people, representing a very diverse county, the selected jury pool consisted of 7 white, middle-aged, college-educated, relatively affluent women, and one older white man.

In the U.S., the right to a trial by jury is foundational - it's specified in the Sixth Amendment to the U.S. Constitution as follows:

In all criminal prosecutions, the accused shall enjoy the right to a speedy and public trial, by an impartial jury of the state and district wherein the crime shall have been committed, which district shall have been previously ascertained by law, and to be informed of the nature and cause of the accusation; to be confronted with the witnesses against him; to have compulsory process for obtaining witnesses in his favor, and to have the assistance of counsel for his defense.

Though it's not commonly considered as such, the U.S. civic duty to provide service as a juror is on par with military service, as illustrated here: https://www.hqmc.marines.mil/News/News-Article-Display/Article/551818/jury-duty-is-civil-duty/

So, it's time to switch things up a little as discussed in the last thread. We're going to have multiple records a week from now on and follow themes rather than the alternating weeks we've had until now.

The first week of our new format is the beginning of a genre introduction series that I'm running: Intro to Shoegaze! We will likely have several different themes switching off each week, and I'll kick off a few over the next couple weeks. These aren't intended to be tailored for genreheads (at least not right now), but rather a way to have a conversation about the all-time greats of specific genres, scenes, labels, etc. while also having something fresh that those already into that kind of music might not already be familiar with.

Shoegaze

Shoegazing (or shoegaze, initially known as "dream pop") is a subgenre of indie and alternative rock that emerged in the United Kingdom in the late 1980s. It is characterised by its ethereal-sounding mixture of obscured vocals, guitar distortion and effects, feedback, and overwhelming volume. The term "shoegazing" was coined by the British music press to ridicule the stage presence of a wave of neo-psychedelic groups who stood still during live performances in a detached, introspective, non-confrontational state with their heads down. This was because the heavy use of effects pedals meant the performers were often looking down at the readouts on their effects pedals during concerts.

Most shoegazing bands drew from the glide guitar template set by My Bloody Valentine on their early EPs and 1988 debut Isn't Anything. A loose label given to the shoegazing scene and other affiliated bands in London in the early 1990s was The Scene That Celebrates Itself. In the early 1990s, shoegazing groups were pushed aside by the American grunge movement and early Britpop acts such as Suede, forcing the relatively unknown bands to break up or reinvent their style altogether. In the 2000s, there was renewed interest in the genre among "nu gaze" bands.

Essential Album: My Bloody Valentine - Loveless - Listen to it!

The shoegaze genre has a pretty much univerally agreed-upon "Big 3" records, the most prominent and influential of which being My Bloody Valentine's Loveless, which is undoubtedly the #1 starting place if you're looking to check out shoegaze for yourself. It's the darling of the genre and of internet music nerdom in general for a reason.

Loveless is the second studio album by English-Irish rock band My Bloody Valentine. It was released on 4 November 1991 in the United Kingdom by Creation Records and in the United States by Sire Records. The album was recorded over a two-year period between 1989 and 1991, with vocalist and guitarist Kevin Shields leading the recording sessions and experimenting with guitar tremolo techniques and tuning systems, samplers, and meticulous production methods. The band cycled through nineteen different studios and many engineers during the album's prolonged recording, with its production cost rumoured to have reached £250,000.

Preceded by the EPs Glider (1990) and Tremolo (1991), Loveless peaked at number 24 on the UK Albums Chart and was widely praised by critics for its sonic innovations and Shields's "virtual reinvention of the guitar". However, after its release, Creation Records owner Alan McGee removed the band from the label, as he found Shields too difficult to work with, a factor alleged to have contributed to the label's eventual bankruptcy. My Bloody Valentine struggled to record a follow-up to the album and broke up in 1997, and Loveless was their last full-length release until MBV in 2013.

Since its release, Loveless has been widely cited by critics as one the greatest albums of the 1990s, a landmark work of the shoegazing subgenre, and as a significant influence on various subsequent artists. In 2012, it was reissued as a two-CD set, including remastered tracks and a previously unreleased half-inch analogue tape version, and peaked on several international charts. In 2013, Loveless was certified silver by the British Phonographic Industry.

Minor Album: Vyva Melinkolya - Vyva Melinkolya - Listen to it!

This one is a shoegaze record which lies a little more on the dream pop / ethereal side of the genre than Loveless, and is my personal album of the year for 2018 so far by a longshot. I would suggest this for anyone who wants to to live in that wonderful dreamy yet noisy middle ground. The artist is also nonbinary, and while I can't speak for everyone, I find that this speaks to gender dysphoria in a way that only the best shoegaze can.

Here's the place to discuss your thoughts on the records, your history with them or the artists, and basically talk about whatever you want to that goes along with Loveless and Vyva Melinkolya! Remember that this is intended to be a slow moving thing, feel free to take your time and comment at any point in the week!

Again, if you'd like to stream or buy the albums, they can be found on most platforms here (Loveless) and here (Vyva Melinkolya).

I myself am a very, very competitive person. Because of this, I play almost exclusively competitive titles that feature a ranked ladder and esports. I find that even on a game that takes care to be competitive, there are still plenty (read: the vast majority) of people that don't seem to care for playing to win, or that don't make any sincere effort to ever improve. There's a guy called Labor on a game I play who plays hundreds and hundreds of ranked matches per season, but plays exactly the same today as he did a year or two ago. He's totally average, stagnant in rank, but keeps playing. Are any of you like Labor? If you are, what do you look for in a game? Even if you aren't, I'm curious. What kinds of games do you play? What types of experiences are you looking for? Why do you look for those experiences?

Preface

Different projects have different use cases that can ultimately result in common solutions not suiting your particular needs. Today I'm going to diverging a bit from my more abstract, generalized topics on code quality and instead focus on a specific project structure example that I encountered.

Background

For a while now, I've found myself being continually frustrated with the state of my project configuration management. I had a single configuration file that would contain all of the configuration options for the various tools I've been using--database, API credentials, etc.--and I kept running into the problem of wanting to test these tools locally while not inadvertently committing and pushing sensitive credentials upstream. For me, part of my security process is ensuring that sensitive access credentials never make it into the repository and to limit access to these credentials to only people who need to be able to access them.

Monolithic Files Cause Monolithic Pain

The first thing I realized was that having a single monolithic configuration file was just terrible practice. There are going to be common configuration options that I want to have in there with default values, such as local database configuration pointing to a database instance running on the same VM as the application. These should always be in the repo, otherwise any dev who spins up an instance of the VM will need to manually tread documentation and copy-paste the missing options into the configuration. This would be incredibly time-consuming, inefficient, and stupid.

I also use different tools which have different configuration options associated with them. Having to dig through a single file containing configuration options for all of these tools to find the ones I need to modify is cumbersome at best. On top of that, having those common configuration options living in the same place that sensitive access credentials do is just asking for a rogue git commit -A to violate the aforementioned security protocol.

Same Problem, Different Structure

My first approach to resolving this problem was breaking the configuration out into separate files, one for each distinct tool. In each file, a "skeleton" config was generated, i.e. each option was given a default empty value. The main config would then only contain config options that are common and shared across the application. To avoid having the sensitive credentials leaked, I then created rules in the .gitignore to exclude these files.

This is where I ran into problem #2. I learned that this just doesn't work. You can either have a file in your repo and have all changes to that file tracked, have the file in your repo and make a local-only change to prevent changes from being tracked, or leave the file out of the repo completely. In my use case, I wanted to be able to leave the file in the repo, treat it as ignored by everyone, and only commit changes to that file when there was a new configuration option I wanted added to it. Git doesn't support this use case whatsoever.

This problem turned out to be really common, but the solution suggested is to have two separate versions of your configuration--one for dev, and one for production--and to have a flag to switch between the two. Given the breaking up of my configuration, I would then need twice as many files to do this, and given my security practices, this would violate the no-upstream rule for sensitive credentials. Worse still, if I had several different kinds of environments with different configuration--local dev, staging, beta, production--then for m such environments and n configuration files, I would need to maintain n*m separate files for configuration alone. Finally, I would need to remember to include a prefix or postfix to each file name any time I needed to retrieve values from a new config file, which is itself an error-prone requirement. Overall, there would be a substantial increase in technical debt. In other words, this approach would not only not help, it would make matters worse!

Borrowing From Linux

After a lot of thought, an idea occurred to me: within Linux systems, there's an /etc/skel/ directory that contains common files that are copied into a new user's home directory when that user is created, e.g. .bashrc and .profile. You can make changes to these files and have them propagate to new users, or you can modify your own personal copy and leave all other new users unaffected. This sounds exactly like the kind of behavior I want to emulate!

Following their example, I took my $APPHOME/config/ directory and placed a skel/ subdirectory inside, which then contained all of the config files with the empty default values within. My .gitignore then looked something like this:

$APPHOME/config/*
!$APPHOME/config/main.php
!$APPHOME/config/skel/
!$APPHOME/config/skel/*
# This last one might not be necessary, but I don't care enough to test it without.

Finally, on deploying my local environment, I simply include a snippet in my script that enters the new skel/ directory and copies any files inside into config/, as long as it doesn't already exist:

cd $APPHOME/config/skel/
for filename in *; do
    if [ ! -f "$APPHOME/config/$filename" ]; then
        cp "$filename" "$APPHOME/config/$filename"
    fi
done

(Note: production environments have a slightly different deployment procedure, as local copies of these config files are saved within a shared directory for all releases to point to via symlink.)

All of these changes ensure that only config/main.php and the files contained within config/skel/ are whitelisted, while all others are ignored, i.e. our local copies that get stored within config/ won't be inadvertently committed and pushed upstream!

Final Thoughts

Common solutions to problems are typically common for a good reason. They're tested, proven, and predictable. But sometimes you find yourself running into cases where the common, well-accepted solution to the problem doesn't work for you. Standards exist to solve a certain class of problems, and sometimes your problem is just different enough for it to matter and for those standards to not apply. Standards are created to address most cases, but edge cases will always exist. In other words, standards are guidelines, not concrete rules.

Sometimes you need to stop thinking about the problem in terms of the standard approach to solving it, and instead break it down into its most abstract, basic form and look for parallels in other solved problems for inspiration. Odds are the problem you're trying to solve isn't as novel as you think it is, and that someone has probably already solved a similar problem before. Parallels, in my experience, are usually a pretty good indicator that you're on the right track.

More importantly, there's a delicate line to tread between needing to use a different approach to solving an edge case problem you have, and needing to restructure your project to eliminate the edge case and allow the standard solution to work. Being able to decide which is more appropriate can have long-lasting repercussions on your ability to manage technical debt.