It's not about looks, it's about functionality. I could add a hundred lines of CSS to make it sparkle without touching Javascript. I could think of a dozen convenience features that would require Javascript, but none that, if disabled, would prevent the search bar from functioning as a search bar.
(imagine this with Christopher Judge's/Teal'c's/Daddy Kratos' voice)
A warrior who seeks only glory through grand and reckless acts is a fool, and will fall to his overconfidence. The wise fight only the battles they are prepared for, and prepare for the battles they are not. If you have done so, then you have done well, and you are stronger for it.
<form method="GET" action="https://duckduckgo.com/">
<input name="q" type="text"/>
<button type="submit">Go</button>
</form>
This is a fully functional search bar. This is all it needs to be. It doesn't need Javascript, only if you want suggestions.
The last time I checked, Google still works if you simply pass your query in the URL using the q
variable. Google has no need to enforce Javascript.
GRUB_CMDLINE_LINUX="rhgb quiet module_blacklist=hid-logitech-hidpp"
and don't forget to run sudo grub2-makecfg -o /boot/grub2/grub.cfg
to apply the changes. When you reboot, press e
on the GRUB screen to make sure the boot parameters are passed correctly.
Hmm... How can I exploit this tragedy to push my own agenda...
I don't know shit about the situation (I don't use twitter), but not being on the same side as Mark "Physiognomy" Kern seems like the right call.
From Wiktionary (I'm not posting a link, look it up yourself):
There have been efforts by those of African descent to reclaim the word (especially in the form n___a), but these efforts are controversial and some people do not believe it is able to be reclaimed due to its fraught history and continued derogatory usage. Regardless, usage by non-blacks is still almost invariably considered highly racist and offensive.
I've done my tests, and it looks like I may have been incorrect.
Point 1. While I was right to suspect the :
character, I discovered that it is permitted in NTFS and only reserved in Windows. When an NTFS volume is mounted in Linux, it only becomes a problem if the windows_names
option is used. Sometimes it is used, sometimes it isn't, and I don't know when.
Point 2. The other thing I found is that Wine only works if the wineprefix is owned by the user. NTFS doesn't understand Unix-style file ownership and permissions, so it must determine the uid, gid, and umask when the volume is mounted. When mounted with OP's fstab entry, it will default to root, so every file (including the wineprefixes) within the volume will appear as being owned by root, which prevents Wine from starting.
This might also explain why mounting the drive dynamically worked, as it probably used udisks2
to mount it as the user.
The solution may be as simple as specifying the uid
and gid
mount options. In a system with a single user, they should both be 1000, but you can check them by running echo $UID $GID
.
The modified fstab entry should be:
UUID=E01A2CEC1A2CC180 /mnt/games ntfs nofail,uid=1000,gid=1000 0 3
This will present all files as being owned by the user, and should allow wine to run.
Point 3. That being said, mixing Windows and Linux is still not a good idea. I don't know what will happen if you create wineprefixes on NTFS. Windows might see the invalid filenames and shit itself. I tried doing it on a new NTFS volume and Windows wouldn't even mount it.
If you really want to keep the game files on the NTFS volume, you might have better luck trying your own symlink fuckery. If you have the Steam library on the NTFS device, you could try moving the .../SteamLibrary/steamapps/compatdata
directory to a Linux filesystem, then creating a symlink in compatdata
's place that points to the moved directory. This method moves the problematic files outside the volume.
The second method involves bringing the game files on the NTFS volume into the default Steam library on the Linux filesystem using a bind mount -- a way to mount a directory at a different mount point. In essence, this replaces the .../steamapps/common
directory with that on the NTFS volume, and avoids creating wineprefixes inside the NTFS filesystem in the first place.
- Mount the NTFS volume using the fstab entry above.
- Assuming that you have the Steam stuff in their default locations, execute
sudo mount --bind /mnt/games/SteamLibrary/steamapps/common ~/.local/share/Steam/steamapps/common
to create the bind mount manually. - Or use the equivalent fstab entry:
/mnt/games/SteamLibrary/steamapps/common /home/salty/.local/share/Steam/steamapps/common none defaults,bind 0 0
Y Combinator probably didn’t do their due diligence
It's not the first time. They also backed an obvious scam MMO that promised the world and more, while it was nothing more than an asset flip.
Not really, because some files in the wineprefix will have invalid names.
When an NTFS volume is mounted, it implicitly uses the windows_names
option, which restricts the character set that can be used in filenames, in order to preserve compatibility with Windows. The specific character in question is the colon -- it is permitted by NTFS, but it's a reserved character in Windows, which means it is also restricted by the windows_names
mount option. This prevents Wine from creating its c:
and z:
symlinks, which are required for Wine to operate.
You could try some symlink fuckery, like linking .../steamapps/common
to the NTFS drive, since all of the problematic files are located outside of that, in .../steamapps/compatdata
. Or you could mount the NTFS volume directly to the common
directory. If you do, I'd love to hear the results.
Relevant issue: https://github.com/storaged-project/udisks/issues/713
NTFS doesn’t support symlinks
It does. You can create them on Windows using the mklink
command. It creates a file link if no switch is passed, directory link with /D
, directory junction (different thing) with /J
, and hardlink with /H
. The ntfs-3g
driver has complete support for links.
Some Windows programs, like the Scoop package manager, make extensive use of symlinks and directory junctions.
The default home page for Microsoft IIS, the web server built into Windows Server (and probably some desktop builds too).