771–780 of 790 posts
Earlier quoted context omitted.
he's not wrong though. ssh is the quickest way of accessing remove machines Invoke-Command -ComputerName $ListOfComputers -Command {#code...}
yes, yes, well done. how does this work with public/private keys again?
Earlier quoted context omitted.
Well, heck even Emacs with some LLVM wrappers can do better job at C++ Intellisense than Visual Studio. Eclipse's CDT runs circles around it as well (so much for being very simplistic). And don't get me started on trying to use Intellisense on large codebases - such as Unreal Engine's source code. It is just completely unusable (30+ seconds before the completion pops up, often blocking your IDE (a total usability no-…
.. if this is you not getting started, I'm kind of frightened for when it does happen ;)
However it does piss me off when I see people uncritically praising VS as the best thing after sliced bread and flat out dismiss the alternatives without even looking at them - when VS is really terrible IDE.
Unfortunately, this is something that is difficult to comprehend for someone who has never seen how it actually could work properly - either because they have never been exposed to the alternatives or because they have the VS-centric "workflow" (more like kludges working around VS silliness) ingrained so deeply that anything else will perturb them.
Earlier quoted context omitted.
I find that to be the issue. You are considering it just RAW text when it is actually formatted text that has been parsable for years with common unix command line tools. It not being in the format you consider a structured object does not mean it's not a object or even parsable. If you are using ad hoc regex I suspect you are not using all the tools available to you. I feel like Kernighan and Pike do a much better j…
> You are considering it just RAW text when it is actually formatted text that has been parsable for years with common unix command line tools. Parsing command output with sed/awk/etc (ie. "common unix command line tools") is absolutely an ad hoc parser. Let me give you an example that I recently ran into. I have a tool that parses the output of "readelf -sW", which dumps symbols and their sizes. The output normally…
Of course the problem with Unix is that there are a thousand different semi-structured text formats, edge cases, and tools that must be mastered before you can make any sense of it all. Any time you point out the pain a Unix fan can just respond by pointing out your ignorance.
Earlier quoted context omitted.
> That's BS. A lot of it's all one executable. That’s not even true if you use the packages for debian or redhat. In both cases, it’s over a dozen packages for systemds independent projects, and you can replace each of them seperately, if you wish to. I’ve done so in the past on a server where I couldn’t update everything because it was an old-style containerized VPS with shared kernel. > Well, if you want Windows, y…
It's not modular, it's a mess. Systemd may be organized into separte components, but make no mistake - it's a monolith in sheep's clothing. As for unit files, nosh, at least, provides the same format as systemd. s6 "unit files" are just the command to daemonize the process, in most cases. BSDinit and OpenRC are pretty simple as well. >Then go and use UNIX, aka BSD. This is the linux world, and most people want it – a…
Sure, it’s theoretically monolithic, but you can replace modules, and it just works.
And "s6 "unit files" are just the command to daemonize the process, in most cases" is a horrible solution, too.
The reason systemd unit files are so awesome is because they’re simple configuration, not having to string complicated commands together.
I configure the user it’s run under, the context, the syslog identifier for stdout, etc.
It all just works.
That’s the big thing.
You fundamentalists had 2 decades to make a working system, yet, what we ended up with was a clusterfuck that was worse than the X11 clusterfuck.
It’s time to end this.
Earlier quoted context omitted.
> I think it doesn't include simply calling external commands proc and inshell. Did you check out the built-in tutorial? http://hackage.haskell.org/package/turtle-1.0.0/docs/Turtle-...
Yes, I skimmed it. But please note that I wrote about "simply" calling external executables, where you can just type the name of a program and have it run. Turtle doesn't even try to allow this (while PowerShell has it), instead going in the opposite direction: > Most of the commands in this library do not actually invoke an external shell or program. Instead, they indirectly wrap other Haskell libraries that bind to…
Earlier quoted context omitted.
It's not modular, it's a mess. Systemd may be organized into separte components, but make no mistake - it's a monolith in sheep's clothing. As for unit files, nosh, at least, provides the same format as systemd. s6 "unit files" are just the command to daemonize the process, in most cases. BSDinit and OpenRC are pretty simple as well. >Then go and use UNIX, aka BSD. This is the linux world, and most people want it – a…
Systemd is to sysvinit what Linux was to Hurd and other microkernels. Sure, it’s theoretically monolithic, but you can replace modules, and it just works . And "s6 "unit files" are just the command to daemonize the process, in most cases" is a horrible solution, too. The reason systemd unit files are so awesome is because they’re simple configuration, not having to string complicated commands together. I configure th…
Show me an example of that being done with systemd.
Earlier quoted context omitted.
It's not modular, it's a mess. Systemd may be organized into separte components, but make no mistake - it's a monolith in sheep's clothing. As for unit files, nosh, at least, provides the same format as systemd. s6 "unit files" are just the command to daemonize the process, in most cases. BSDinit and OpenRC are pretty simple as well. >Then go and use UNIX, aka BSD. This is the linux world, and most people want it – a…
Systemd is to sysvinit what Linux was to Hurd and other microkernels. Sure, it’s theoretically monolithic, but you can replace modules, and it just works . And "s6 "unit files" are just the command to daemonize the process, in most cases" is a horrible solution, too. The reason systemd unit files are so awesome is because they’re simple configuration, not having to string complicated commands together. I configure th…
That's just not true. Linux was a return to a simple, tried-and-true model from a more complicated and theoretically beneficial one. Systemd is a devergance from a simple, tried-and-true model to a more complicated one, that really doesn't have many benefits.
>And "s6 "unit files" are just the command to daemonize the process, in most cases" is a horrible solution, too.
>The reason systemd unit files are so awesome is because they’re simple configuration, not having to string complicated commands together.
So are S6 unit files. So are a lot of config formats, actually. Sysvinit was really bad, but other inits had moved on. The complicated commands are only required when the app had complex requirements, or when init is stuck using fragile pid handling, which S6 and the like don't need, because they implement proper process monitoring.
>You fundamentalists had 2 decades to make a working system
BSDinit, OpenRC, s6, hell, even upstart, and countless others are all working systems.
Anyways, I'm not a fundamentalist. I don't think that systemd's unit files are broken. What I think IS broken is systemd itself.
Init has a few jobs: managing startup, managing shutdown, reaping processes, and handling daemons, etc. By this point, init's job is well defined. How it should do them has been argued, but the jobs are well defined. That is what init should do. NOTHING ELSE.
Systemd tries to do everything. Thus, it's overly complex, AND it's a single point of failure.
>It’s time to end this.
I quite agree: When Lennart stops making me try to use his piece of trash disguised as software, I'll stop complaining about it.
Earlier quoted context omitted.
> text "scraping" is just better for most cases. Unix pipes handle bytes, not just text. For instance, copy a hard disk partition to a remote hard disk via ssh: (dd if=/dev/hda1) | (ssh root@host dd of=/dev/sda1) The KISS principle ("Keep it simple, Stupid") is the best way in many cases. In Unix you can quickly enter a pipe without special coding which does also non-trivial stuff. For instance, find -name "*.xls" -e…
> Can you do this in Powershell quickly? I don't know, I am actually curious. You can basically do the same thing with Powershell. I don't know of a 'built-in' module to handle XLS->CSV conversion, so you need to bring one in: Install-Module ImportExcel Then: ls *.xlsx -r | %{ Import-excel $_ } | ? { $_.Name -eq "Miller" } | sort That's my naive, Powershell noob approach anyway. There's another option however, where…
Earlier quoted context omitted.
Passing CSV around can be a useful middle ground, if you're using utilities that all do proper escaping and allow newlines in strings etc., such as csvkit.
DSV is the default format for many unix utils, and AWK and cut parse it easily.