You may find it interesting that recently Malwarebytes was mentioned in relation to 230 of the DMCA which to my mind relates directly to this. They are an AV solution that holds "legitimate" software vendors that operate an above board business to the fire when they start any practice that they (Malwarebytes) determines is violating a PC users reasonable expectations. That software begins to be detected as "potentially unwanted software" and recommended for quarantine just like any other virus.
Malwarebytes spends a whole lot of time defending the fact it recommends software from these companies for removal and the recent SCOTUS memo on the topic sort of implies that the problem -- how do we determine the voracity of statements made by businesses regarding their software, especially software which exists in a constantly changing state -- may be headed towards getting worse as so few people are familiar with legislation also have good understanding of the inherent complexity of software.
Tangent: Cheat Engine, an amazing piece of software, mentions on their website that they may be detected as malicious software because they do a lot of the same things malicious software does - hook into other processes and modify their behaviour, optionally with a kernel hook.
They don't mention that their installer ships with tons of malware that they install, and more that they try to trick you into installing but you can technically opt-out.
I was very much a part of this community at the time and engaged in a lot of discussions around this "feature". Part of the issue is that there were degrees of bunny hopping (as in being able to do it extremely well and consistently) and script assisted bunny hops were also becoming a thing. This was also around the advent of aimbotting finally reaching the half-life engine and there was a real discussion about turning new players away from the game because of these "pro features".
Ultimately it wasn't part of the intended game design, despite being a bit of a fun imaginary minigame within the greater 5v5, and I agree it was the best choice for all the mods around that time (CS wasn't the only one you could bhop in).
To add to this anecdote though, knife scraping on a wall when the round is down to 1v1 was almost always universally "come knife fight me" and for the many times I've seen players arrange this duel I rarely see either try to "cheat" and shoot the other.
IAM is going to be "required" for the root account, though, shutting that away is a good practice.
In lieu of IAM you can use federated access from an identity provider like Okta. That will lease a role which can then adopt other roles (even across accounts). Okta is integrated with a more formal IT system like Active Directory and then all your accesses and identity can be managed by them. I think this is the AWS side doc for the setup https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
Now I understand - you are talking about IAM users versus assumed roles, instance roles, and the like. Definitely a best practice to utilize those over IAM users but you never get away from IAM entirely, its the corner stone of all access control within AWS. Difference is that with assumed roles and similar you get short lived credentials that need to be renewed periodically (usually behind the scenes) whereas IAM user credentials exist until you remove them (though best practice is to rotate them periodically.) There are some instances where you can't get away from them easily - remote access to S3 buckets is a biggie, even though I can get assumed role credentials through my identity provider, I've yet to find an S3 client (besides the cli) that can utilize them. Access to SES for applications that need raw SMTP credentials from an IAM user. My CDN can make requests to S3 buckets with AWS v2 signatures, that needs IAM user credentials also (though the actual policy is limited to the buckets with public content and only getting known objects, no listing).
Just as someone who got on the Ruby bandwagon back in the mid 00's there was definitely a feel of Ruby being a "Japanese import language" and at the time for myself, comparing Matz and van Rossom the latter felt like a little bit more of a scientist/engineer than the former who seemed very humanity focused.
Also I think the mantra of "developer happiness is the #1 goal of ruby" kind of makes ruby seem a bit more fanciful and flowery than python.
These are just my personal anecdotes, though, I am assuming that most people (myself included) start eyeing seemingly superficial things like the attitude of the language author when a lot of other qualities of the language are similar.
I tried very hard to take the perspective that this guy is irritated but that there might be some substance to his opinion. I couldn't help but constantly think this, though, "Wow, this guy is really mad, and now wants to logically apply blame to everyone and everything except himself and his choices."
I spent the last 2 hours of every work day using VIM, regardless of how much longer it took to work on things. By the end of the week, I could jump into vim after lunch. When I started using ':x' in TextMate I knew it was time to leave.
I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact).
I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out command).
I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.
I actually like that feature. I try to stay out of insert mode as much as possible. This feature lets me mash C-w or even C-u without worrying about changing text outside the original scope of my edit. I use the c command to change text inside of an html tag (for example) and I like that this protects me from damaging the tag itself.
That's the way vi is supposed to work, since it is based on the paradigm of a modal editor.
I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.
vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.
(As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)
I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.
UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.
Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos.
UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.
Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script.
Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair.
The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care.
Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with!
Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion.
UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system.
On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions!
On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.)
It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records?
This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range.
UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX.
If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.
You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.
No they do not, what in the world gave you that impression?
UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expect the OS to work.
Even so, a desktop environment on UNIX is just yet another application, sometimes it is just a single process. The operating system empathically does not provide any kind of file type recognition or handling for such a desktop environment application, and any such file type recognition and handling is proprietary to that application.
Since the core UNIX paradigm is one of everything is a file, and all files are nothing but a stream of bytes, the OS has no concept about the contents .h, .c, not shell scripts, let alone .wav, .au, or .mp3 files, for instance. The UNIX operating systems only deliver streams of bytes at the request of applications via the open(2) and read(2) system calls. That's policy. The mechanism of what applications (consumers) of that or those byte streams do with the stream is left up to the applications which consume the streams:
A Unix File Is Just a Big Bag of Bytes
A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.
That is KDE specific, and has nothing whatsoever to do with the OS.
How does your KDE handle file types when you are logged into a headless server, without any kind of graphics hardware, and your console is a serial port? How does the UNIX kernel handle file types when you're on a headless server with no graphics hardware, and your output is stdout on a teletype terminal or a nullmodem cable on a serial port?
I guess you missed the point of everything I've written so far. Did you read the links I provided?
Upvoted! Same here; I hate it when syntax highlighting makes it difficult for me to see the code, when I'm on a server and am just trying to get some work done. I cannot comprehend why I would want to see code in all those colors, with horrible contrasts, hard to read? Why? I know the syntax of the code, don't need or want anyone shoving what they think I need or want down my proverbial throat!
