91–100 of 162 posts
Earlier quoted context omitted.
That's different. Apple as a trademark for a computer (or for a record company) is fine. Apple as a trademark for apples... not so.
Just that the "difference" stops when they now sue any grocery related company having anything like an apple in their logos..
Did some fancy DB work for them on OS/2 and early AS/400s in the '90s.
Earlier quoted context omitted.
Just that the "difference" stops when they now sue any grocery related company having anything like an apple in their logos..
Apple did complain about this logo too, for a bicycle route through Germany's second largest apple growing region: https://apfelroute.nrw/
Earlier quoted context omitted.
Murex ( https://GitHub.com/lmorg/murex ) doesn’t replace coreutils with builtins but manages interop with commands just fine. Most output is relatively easy to parse, sometimes you need to annotate the pipe with what format to expect but that’s easy enough to do. And Murex does come with builtins that cover some of the more common coreutils use cases for instances when you want greater assurances of the quality of th…
That's the first time I'm hearing about this project (which I take you are the creator of?). Very interesting! How would you say Murex compares to Nushell? The syntax seems vaguely similar. Are there any fundamental differences?
Murex was created before most of the alt shells existed, created to scratch a personal itch. It's only relatively recently that I've been promoting it. What I wanted to create was a shell that had typed pipes but still worked 100% with traditional POSIX abstractions. So it's still just standard POSIX pipes underneath so type information is sent out-of-band. This basically means you can have a richer set of functionality from anything that understands Murex while still falling back to plain old byte streams for anything that doesn't.
I've also taken inspiration from IDEs with regards to the interactive UX. You'll get syntax highlighting, dynamic autocompletions based from man pages (I'm shortly going to push an enhancement in that area as well), smarter hints (like tool tips), inline spell checking, and all sorts.
There's also been some focus on making the shell more robust. Such as built in unit test framework, watches (for debugging), etc.
There will still be plenty of rough edges (as is the case with all shells to be honest) but it's a vast improvement over Bash in my biased opinion. So much so that it's been my primary shell for > 5 years.
Earlier quoted context omitted.
Agreed. Nushell fulfills the Unix philosophy promise that the standard Unix tools have been breaking since forever. Traditional Unix commands feel like a hodgepodge of hacks by comparison, that only work together occasionally, and even then mostly by accident.
The Unix philosophy doesn't dictate any specific data format to interoperate between commands, besides this being data streams, and typically text. Commands are free to interpret these streams however they want, which is why this seems like "hodgepodge", but in no way were tools breaking any sort of promise. FWIW I've been using *nix machines for decades, and very rarely have I had the need to use structured data bet…
In my profressional life I have cause to work with Powershell a great deal, and I love the object oriented pipelines that it has. Being able to filter, sort, or transform properties of the objects passed over makes it much more straightforward to work with than bash et al.
I had an idea where I'd make wrappers for all the popular commands that would accept JSON structured data instead of raw binary data and "do the right thing". And that way you could take advantage of it without having to change your shell tooling. And they'd all accept an extra argument called either --structured-out or --unstructured-out which would either emit JSON or render the output back to a "flat" string, as appropriate.
[flagged]
The very thing you touched on is literally mentioned in like the 2nd paragraph.
Earlier quoted context omitted.
Sure, but the reason it works with any tool is because it's generic and simple. If each tool had to implement anything more sophisticated like a JSON parser and serializer, it would be a nightmare to maintain. Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. Subtle changes in this s…
> Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. I think you're misunderstanding how Nushell works. They don't parse outputs, or generate inputs, from/for standard Unix commands. Instead, they implement their own commands with the same names as standard commands, and generate/cons…
But, hey, this obviously has users who prefer it, so if this works for you, that's great. Personally, I'll stick to the standard GNU and POSIX tools. I do concede that this is partly due to the robustness of this ecosystem and my familiarity with it, which is hard to abandon.
> Saying that unstructured text streams are a universal interface is like saying that atoms are a universal construction kit – it's technically correct, but pretty useless in practice.
My point is that offloading the decision of how the tools are integrated beyond raw byte streams to the user, is the most flexible and future-proof approach, with the least overhead for individual tools. Doing anything more sophisticated, while potentially easier for the user, would require maintenance of the glue layer by each tool's developer, or a central maintainer ala Nushell. This loose coupling is a good thing.
Earlier quoted context omitted.
That is not what the thing you quoted says, or even correct. All duct tape is made of fabric and it is… well duct tape, so ducts were the intended use case when the name was created. Duct tape has kinda become a general term for all cloth-based tapes though, so you can indeed find duct tape not intended for ducts, but the fact the name was originally “duck tape” has nothing to do with that.
ASHRAE/UMC actually specify tape 'for ducts' to be UL 181A-P/181B-FX [0] which is commonly made of metal foil and not cloth. [0] https://tapeuniversity.com/products/foil-tapes/ul181ap-ul181...
Even your own source on a separate page [3] says:
> After the war, duct tape became popular with the general public. One popular use was holding together ventilation ducts. Ironically, while this is a use that duct tape does not normally have today, the name stuck and is used to this day.
So I am now confused.
[0] https://www.chicagotribune.com/redeye/redeye-is-it-duck-or-d... [1] https://en.m.wiktionary.org/wiki/duct_tape [2] http://www.todayifoundout.com/index.php/2010/02/duct-tape-wa... [3] https://tapeuniversity.com/industry/building-construction/du...