DACs are very cheap (second hand and AliExpress) and they never use much W. If both machines are near each other though (which a DAC cable implies) and both run Linux and both support Thunderbolt, you might be better off with a direct ethernet over TB connection. Whether macOS supports such, I don't know.
The other side will then also need a low power NIC (of which fiber and DAC over SFP+ are less power hungry). What this article doesn't mention, is that there are also a lot of PCIe NICs on the market which aren't power hungry (RTL8127), as well as RTL8261C for switches/routers.
I've seen low power RTL NICs with SFP+ on it, too (example: [1]). With SFP+, you'll have a lot more versatility. DAC and SFP+ fiber are very cheap, btw. Especially second hand they go for virtually nothing. I have 10 SFP+ fiber lying around here doing nothing which I got for a few EUR each.
For me as European with high energy prices and solar energy gotten the beat next year (in NL), this is all very interesting.
There's a couple of good reasons why to opt for fiber in the home. You keep the energy between the different groups separated which can help. I also find fiber very easy to get through walls, allowing me to have multiple fiber connections through walls (currently I use 1x fiber + 1x ethernet for PoE possibilities from fusebox).
With all above being said, AQC100S is low power and does not get very hot. You can get these with SFP+ and PCIe/TB. They've been available for a while.
I just wish someone would come out with a PCIE 4x1 capable card with SFP - my main desktop’s non-GPU expansion slots are all 4x1 electrically and even the one you linked is a 3x2. As far as I can tell the only 4x1 cards available are RTL8127 or AQC113 RJ45 ones :(
I suppose an NVME riser is also an option, albeit janky.
Right, but I don’t think a x2 slot exists so hence being physically a x4 card. If you had an open ended x1 slot you might be able to run as PCIe v4 x1.
Veganism is a terrible example in this context because that community is riddled with all or nothing dogma.
If people were pragmatic instead, and the vegan community would quit alienating people the non-perfect, non-purists the world would be slightly better, too.
For example, in my country licorice is popular. Whether it contsins gelatin or not, not one pig less will be killed because it is a by-product.
10 years ago, I went to a workshop (with DIY) on how to make vegetarian and vegan sausages, and since you mention sausage, I'll use that as another example. A sausage contains herbs and vegetables (to develop taste) and certain chemistry (= cooking) techniques, for example salt and to keep the product together. It is relatively easy to make something akin to that yourself. Heck, one can sauté carrots and build something akin to a hotdog fairly easy.
Comparing it to gelatin is unrealistic, but to say sausages are made from the best meat of the animal? No, minced meat is not since then they wouldn't mince it (as rule of thumb). Frikadel is another example eaten a lot here (NL), the Germans also got their sausage culture.
Meanwhile, there's a much more dramatic example: chicken. There's a lot less meat on those birds per serving, so suffering per human/day on avg omni diet is much worse. But does that mean one should avoid free range chicken eggs? No.
And that is ignoring the environmental impact, since there too a vegan diet (with avocado and almonds requiring a plethora of water and movement of product to market) isn't ideal either (the latter might be less of issue for say Cali).
So in short, we should welcome those people who love bacon to 1) consume less bacon 2) try vegn alternatives. But it doesn't have to be either they're vegan or omni 24/7. Flexitarianism is much more reasonable for a lot of people, and also many situations can arise where such is desirable (such as gifted food, festivities, etc).
Written by someone who follows a pragmatic vegn diet.
Why not? That is just a matter of porting stuff over, like a FreeBSD ports collection, an apt repo, or a bunch of scripts for Proton/Wine such as Lutris.
Cygwin started in 1995. Microsoft wasn't cooperative with FOSS at all at that point. They were practicing EEE, and eating some expensive Unix/VMS machines with WNT.
Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995.
The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL.
Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...).
Those constraints also meant native applications instead of Web 2.0 NodeJS and what not. Java specifically had a bad name, and back then not even a coherent UI toolkit.
Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe.
The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.
As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy?
Not so much.
I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.
Slow forking is only the second biggest problem IMO. The biggest is the lack of proper signals. There's a bunch of software out there that just isn't architected to work well without non-cooperative preemption.
That's fake cooperative emulation of signals. It isn't preemptive (unless someone got a kernel driver approved while I wasn't looking?) thus many things either work poorly or not at all. Pause-the-world GC algorithms are a good example. Coroutine implementations also have to be cooperative.
If you're curious, I believe the issue was discussed at length in the Go GitHub issues years ago. Also on the mailing lists of many other languages.
I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that).
> slow forking
There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort.
Cygwin can't do anything about the cost of forking processes, unfortunately.
Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions.
For example, someone might do something like this (completely ignoring the need to quote in the interests of illustrating the actual issue, forking):
for x in *; do
new_name=$(echo $x | sed 's/old/new/')
mv $x $new_name
done
Instead of something like this:
for x in *; do
echo $x
done | sed -r 's|(.*)old(.*)|mv \1old\2 \1new\2|' | grep '^mv ' | bash
This avoids a sed invocation per loop and eliminates self-renames, but it's harder to work with.
Of course the code as written is completely unusuable in the presence of spaces or other weird characters in filenames, do not use this.
To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?
If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.
You don’t get an app that looks the same across platforms. You do get apps that look like they belong on your platform, even though the code is cross-platform. It uses the native toolkit no matter where you run it across Windows, GTK, Qt, Motif, macOS/Carbon, macOS/Cocoa, and X11 with generic widgets.
Older platforms are also supported, like OS/2, Irix, and OSF/1.
It’s a C++ project, but it has bindings for most of the languages you’d use to build an application. Ada? Go? Delphi? Ruby? Python? Rust? Yes, and more.
https://wiki.wxwidgets.org/Bindings
I wish the Wx proponents would stop saying these things. Who exactly are you trying to fool? Do you have no concept of reputational damage? What good comes from a claim that is so easily disproven by just installing a Wx application and looking?
Do you understand the difference between a toolkit API and a graphical widget?
I’m not trying to fool anyone. I'm not affiliated with the project. I’m just aware of it and have used it a few times. You, on the other hand, have called me a liar and a fraud because I repeated exactly what the project docs state and which your two links do nothing to contradict. In fact, you linked to yourself being corrected by the actual maintainer of the project. Did you read anything he wrote?
> Do you understand the difference between a toolkit API and a graphical widget?
I think I do. I have taken a few minutes on the Web to compare that what I had in mind is correct. What was the point of asking this question? Was it to trap me in a gotcha, or paint me as clueless, or what?
> have called me a liar and a fraud because I repeated exactly what the project docs state
Good, you realise you are taking on the claims made by Wx on paper. However, there's more to the world. To get the full picture, you have to also engage with what I have listed. The docs say one thing, the reality shown in the screenshots say another. There is a contradiction. It remains unresolved, not for lack of trying on my part.
> your two links do nothing to contradict
You are not further allowed by me to invalidate what I was writing about by simply disregarding the evidence. Engage with the points I was making. The differences in look and feel between Wx and native are plain for everyone to see and verify. So, what now? Who is right?
> Did you read anything he wrote?
Yes. Examine this:
his claim> OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native
his deflection> Sorry, I don't know what is this supposed to prove
So instead of admitting that there is a contradiction, he just pretends to not understand it.
Also examine this:
> look good
> look good
> looks fine
> look good
I never mentioned anything about looking good, this is a distraction designed to deflect from the central point I was making. As I wrote before, the central point made by me remains completely unaddressed.
Alas, I cannot deal with those crazy-making techniques, his behaviour measured by outcome is indistinguishable from the mentally ill. With the help and advice from a friend, I came to the conclusion that it was not safe for me to respond, so I then decided not to.
I don’t really care what you “allow” me to do, and I don’t owe you my time for a deep rebuttal of your claims.
I accept that you’ve had a bad experience with the project and that you are speaking in good faith about that experience. I do not accept that I’m a liar or a shill because my experience does not match yours, and you will not convince me to accept that.
Whatever has gone on in other places between you and some third party has nothing to do with me. I didn’t see any credible threat to your safety in the links you shared, but I’m willing to guess that’s not the complete story between the two of you. I really can’t and won’t be dragged into the middle of that, because I don’t know either of you.
I notice you did not address the central point. This is, of course, because you are unable to. You have no argument to attack the evidence I have shown, you cannot answer any of the questions I have posed, the sidetrack about the other HN user was fruitless, you rationally know you are holding on to an indefensible position. And yet… the fragile ego cannot allow admission of being wrong, or even merely entertain the thought. So "muh experience is different" emotional cope comes out instead of dealing with objective reality, like installing a Wx software or looking at a screenshot. Stop digging, man, we already feel embarrassed on your behalf.
If you can read someone’s thoughts so thoroughly you should be making a living playing poker. All you have cited as evidence is your own other posts. You just have to have the last word, though, and that word has to be an insult to a stranger.
The problem is, most of these bindings are out-of-date. Delphi from 2012, Basic from 2002, D from 2016. wxRuby is a dead link. wxAda was already dead in 2009, as the discussion I can google suggests.
So, if you use wxWidgets, you probably have to use either C++ or Python version, others are unlikely to be supported.
I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes.
I'm sure they did the best they could ... it was just really painful to use.
This matches me experience as well. Some of my earliest rsync experiences were with the Cygwin version and I can remember scratching my head and wondering why people raved about this tool that ran so slowly. Imagine my surprise when I tried it on Linux. Night and day!
It's not just DLL hell. Cygwin was also notorious for being really out of date. Security vulnerabilities and missing features were both very common at one point.
I have used cygwin for 30 years and never had any dll hell issues, because all the programs came from the cygwin installer. Never once needed something outside it.
Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
After severe cramps once when I had to use a lot of ibuprofen (dental surgery / wisdom tooth) I now only use ibuprofen with a stomach protector to avoid stomach cramps, H. Pylori, and reflux.
Acetaminophen is part of ECA stack weight loss formula, while article says not OK with fasting. Either way, more safe solutions are known these days.
Historically it is correct, and the movie Rambo III even references to it (such movies are made with approval of US military).
Stuff like this happens all the time though. You give resources to the enemy of an enemy (temp. friend) and they may end up as your enemy with the demise of your common enemy. Ideal allies you have a lot in common with (shared values) which was true regarding Europe and USA last century.
And lies and deception, all the time. I don't understand how a devout Christian can support such, except if I regard religion as tool and these people not religious at all. The hypocrisy level is too damn high.
Besides, he doesn't treat women with respect either, and he seems to like to visit prostitutes.
That, and a whole lot more. We are scratching surfaces here.
IPv4 usage in its current state would've been much more limited and annoying in a world without IPv6. Therefore, IPv4 exists as-is thanks to others adopting IPv6.
The other side will then also need a low power NIC (of which fiber and DAC over SFP+ are less power hungry). What this article doesn't mention, is that there are also a lot of PCIe NICs on the market which aren't power hungry (RTL8127), as well as RTL8261C for switches/routers.
I've seen low power RTL NICs with SFP+ on it, too (example: [1]). With SFP+, you'll have a lot more versatility. DAC and SFP+ fiber are very cheap, btw. Especially second hand they go for virtually nothing. I have 10 SFP+ fiber lying around here doing nothing which I got for a few EUR each.
For me as European with high energy prices and solar energy gotten the beat next year (in NL), this is all very interesting.
There's a couple of good reasons why to opt for fiber in the home. You keep the energy between the different groups separated which can help. I also find fiber very easy to get through walls, allowing me to have multiple fiber connections through walls (currently I use 1x fiber + 1x ethernet for PoE possibilities from fusebox).
With all above being said, AQC100S is low power and does not get very hot. You can get these with SFP+ and PCIe/TB. They've been available for a while.
[1] https://nl.aliexpress.com/item/1005011733192115.html (no vouching for, just first hit on search)
reply