Replies: 6 comments 34 replies
-
|
I believe their decision is final thus I'm not surprised you didn't get friendly responses although the T6224 seems to be gone now so I don't have idea what happened there... I wouldn't take their response too seriously - at the end they are just excuses. It's silly to think that small ISP made fortune by using VyOS and they know too. We can always dream about fork... I don't see a way I can use VyOS unless I play by their rules. Thus for me it's more question if they deliver on their promises (Stream) and then see what it will be like and perhaps the Stream could work for many. I don't really care about the LTS or sagitta, I don't see reason I couldn't use bookworm based VyOS as circinus is - if the source is available and the result is predictable. There is no news on this subject though and last query about this on reddit got hostile response, some posts were deleted as well. |
Beta Was this translation helpful? Give feedback.
-
The embedded devices are different world since the "GPL source" may not help you anyway. Many of these devices rely heavily on hardware offloading, their tiny CPU can't do anything, thus they are offloading many tasks to custom accelerators via proprietary modules. You could extract those binaries from their firmware file but that's not straightforward. Also it would challenge to create valid firmware payload depending how much the manufacturer did try to stop you from doing so. You likely can extract the rootfs via binwalk -e but where to go from there? Who knows, this depends on the device and it generally isn't easy and sometimes even possible thanks to key singing.
That was meant as easy / straightforward way to build image - eg. you would need to write your own build system. If they want to sell custom images from $12k and up then they need to make sure you can't easily bypass this artificial limitation by asking for the source... That would too easy! Although even if they give you the least friendly version of the source, you can still build it. Well I assume that ALL portions of VyOS are GPL. That's why I expect they will have ban list of those with GPL tendencies 😄. If you think about it - then if you ask for source and you can build images, then you can bypass their whole pricing structure and "generate" $12k subscription of capability from the least expensive option. So there is good reason to get rid of those GPL thinking people!
They written foreshadowing here https://forum.vyos.io/t/lts-release-package-repositories-permanently-closed-for-public-access/14637
Two weeks-ish after the closure - so that was quite expedited "warning".
Back then they did seek funding. Now they have enough profits to fund everything and thus they want to grow revenue instead. In this context they will never want the $25 since as I said before that would mean to give away those tens of thousands they get otherwise. The only world where the $25 would make sense is if they cripple the $25 version in way where it's unusable for the commercial users - so the subscribers won't have a choice other than to pay the higher option.
The definition varies by who is supposed to be "shit-talking", but anything they don't want to hear can be shit-talking and if you include rudeness then that's a ban! Well, they don't ban people - they delete their account instead. They also delete other posts around the time of ban. They cleanup the whole situation! |
Beta Was this translation helpful? Give feedback.
-
|
Phicomm KE2M appears to be based on MediaTek MT7628NN, that chip is also in some routers supported by OpenWrt but this model was too cheap (little RAM/flash) to be supported. I wish I had the time to do some hardware hacking (serial console, maybe JTAG) like I was doing with RTL8181 about 20 years ago. It started with partly open Realtek SDK, later there was fully open source LInux port including 802.11b wireless, unfortunately the hardware has become obsolete soon after... and I even made an un-brick tool that was a real hack as one had to give the CPU some MIPS opcodes to run by emulating a very slow external memory via JTAG bit-banged over a parallel port, PCI parallel ports were faster but still took a few minutes to dump the flash. And yes I shared that for free (also un-bricked a few devices for a fee to help a few people not familiar enough with electronics, back when hardware cost was higher than labor cost). Well it's either "sell custom images" (must be hard for anyone else to build from source) or "have many open source contributors" (must be easy for contributors to build and hack on the source) - but they want to have the cake and eat it too... The usual well accepted non-controversial solutions are to offer support services, partner with hardware vendors, have a foundation to help funding (they planned one but it never started, I guess not needed anymore). I guess that was the plan then the big $$$ deal came so the community no longer needed. It was not two but six weeks (from 25 April to 5 June), one would hope they at least wouldn't stab in the back those who helped them grow. I didn't distribute their precious LTS images to third parties, but still was treated like I did. And they invent excuses for things that could have been prevented (trademarked logo/artwork - why not remove just them from public source, and only include in their official builds, then no one will ever confuse self-built "CentOS of VyOS" images with the official ones), so much talk about their reputation but if they publicly abuse people that's OK because it's their own bugtracker/forum their rules. Probably all we can do is spread the word, maybe some journalist would be interested who knows... |
Beta Was this translation helpful? Give feedback.
-
Exactly, they wanted to fund the project at first, but then they did discover they have cash cow at hands and now there is no way back. It was fun while it lasted.
I think of it as they do it for their own good if they fabricate all the various reasons why it's justified to do all the things they did. If they said it was just because of greed, that would be bad marketing and maybe they don't want accept this reality by themselves that they did need to stab the community multiple times just because of greed, for their sanity.
I see this as trend, there are numero instances of this so I don't think this is shocking at all. And you can't complain because their job is to make money, if the project is developed by commercial company. Be always suspicious of open-source run by commercial companies because they could be building their product thanks to the community with aim to pivot once they have foothold in the market. Even if they don't have this plan from start it's unlikely they don't get ideas if they see other projects where it worked real good... There is no doubt that the "marketing" of the community is very powerful even if the community doesn't contribute to the development itself much. What would be VyOS if they didn't have their community? DANOS? 🤔 There is still chance that the Stream would be alternative so this could end reasonably, but I'm not quite sure if the Stream will happen. It's kind of hard to imagine they would give community anything with their current attitude 🤔. We shall see. |
Beta Was this translation helpful? Give feedback.
-
|
Well only time will tell what happens to the projects I use, XCP-NG and TrueNAS. Good thing is that they are very stable and just work, I don't need to upgrade unless some big security hole is discovered (but the VMs are all mine, not under control of third parties). Also I've just opened a PR for the main README.md to better reflect reality - vyos/.github#62 (maybe "required" is a bit strong but I didn't want to go into too much details like "required if you don't like to be abused" etc.) |
Beta Was this translation helpful? Give feedback.
-
|
I would say the XCP-NG and TrueNAS would be much easier to replace anyway, because there isn't such strong "vendor lock-in" as is with the router. Both because of complexity of given device and also because testing the router is especially difficult compared to anything else. If the day will come it won't be a big deal. I run both NASes and VMs (KVM+libvirt) in plain Debian, it's quite strainfoward and it just works. I did use pure xen on top of Debian too, that did work just fine as well, but it was bit more complicated. The libvirt can manage basically anything tho. I run plain Debian everywhere only the VyOS was special and how that went 😄. |
Beta Was this translation helpful? Give feedback.
-
|
Hidden now, but here is a copy saved from my email. @GurliGebis was also in Cc - just to verify it's the same, I haven't edited anything. |
Beta Was this translation helpful? Give feedback.
-
|
They just made it public again - interresting... |
Beta Was this translation helpful? Give feedback.
-
|
Well it's not easy to delete something from the Internet... |
Beta Was this translation helpful? Give feedback.
-
|
All that this has proved to me, is that you cannot trust a word coming out of their mouths. They could have been honest to begik with, even though I wouldn't have been a fan, I would have respected it, and actually to a certain extend agree with them. But instead they have shown not to be trustworthy, which has just resulted in people start campaigning to spread the word. They complain about people not contributing, and then start acting like that. Maybe this repo should have a github.io page, explaining why you shouldn't contribute to VyOS? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe not directly negative "why you shouldn't" (even though such negative campaigns quite often win elections... and I mean not just the US, here in PL it happened too) but getting some facts straight so people can hopefully draw their own conclusions. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't poked around the source very much yet, but does VyOS patch or modify (m)any of the packages it uses in any special or meaningful way? I'm wondering how much of just the configuration/frontend we could use on its own in a fork |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Out of that list, which ones are actually required or meaningful though? I've given a few of them a quick skim, and some of them seem like nice things that aren't really necessary, or things that could be upstreamed? (Another way I'm thinking about this: if I were to forgo VyOS and use Debian directly as a router/firewall with those packages, which of those patches should I really be considering applying to my system?) |
Beta Was this translation helpful? Give feedback.
-
|
You can assume that every single custom change has a use-case, but it's very unlikely that's your use-case. If you limit the scope to single use-case, then you need only fraction of the VyOS functionality and no flexibility. Thus what out of the custom changes are essential? I would say very little or nothing at all. That's why I would start with plain Debian - I wouldn't use custom changes unless I have good reason to do so. All the changes are solving some kind of problem but if you don't have any problems - then you can ignore it all - and it's better since the less custom changes you have, the less you have to worry about. |
Beta Was this translation helpful? Give feedback.
-
|
It's interesting to me though, that those use cases aren't important enough for the projects themselves to include/upstream — I would want to understand why. Perhaps, there was just no effort made to upstream the changes? Or, perhaps the patches solve a problem that should be solved a different way? Or, they fix something that VyOS itself made a problem? I am just spit balling, of course Of course, I am thinking about this in terms of a fork, and hoping we would not have to maintain a bunch of forks of packages we want to use. I would much rather spend the time upstreaming things than building custom versions of packages, personally |
Beta Was this translation helpful? Give feedback.
-
|
How much they try? Who knows. I know that bunch of patches aren't made by them, like they are originating from different sources. This tells you that the upstreaming in given case isn't that easy. Some patches are specific to VyOS for sure, they change build configuration for example. There are many reasons why you would have patches, look at Debian, it has gigantic repository of patches for countless different packages. In Debian's case that's mainly because they support the version they included and this version may not be the latest supported officially (the patch may even come from the upstream just from different branch/version). Sometimes Debian includes package that isn't supported at all, like the upstream development ended or it's stale. This will be factor in VyOS too if you look at older LTS branches. I don't think the overhead is significant for the VyOS since many of the patches didn't change for long time and they don't have that many patches and also the patches are generally small. They just sit there. There were for sure cases where VyOS had a patch and the change was included upstream eventually, somehow, so the patch was dropped. Many reasons, many factors, it depends... It's not that simple. It boils down to not applicable or too difficult. |
Beta Was this translation helpful? Give feedback.
-
|
Hi All! Is that working to build latest 1.4.1 version or not?Is that stable for now? |
Beta Was this translation helpful? Give feedback.
-
|
No, since 1.4.0 the source code on public GitHub wasn't updated. The development of stable branches is now behind closed doors - there is no way to build 1.4.1 from official public sources (or any other up to date stable branch). There are no publicly available up to date sources for stable branches as far as I know. Only the development (current) branch is still public, anything else isn't anymore and what is available is abandoned (~3 months old). |
Beta Was this translation helpful? Give feedback.
-
|
Sadly to hear that :( |
Beta Was this translation helpful? Give feedback.
-
|
Is it still possible to build 1.4.0? I just found this yesterday and I hoped it would be a way out of a situation it seems others here are in. I started with edgeos (which was essentially abandoned by the vendor), switched to vyos and then to opnsense. I'm actually pretty happy with opensense except its performance is terrible on KVM. I get 25Gbs VM to VM on my i7 with linux VMs and 2.5Gbs with the BSD VM :( |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the source for sagitta/1.4.x wasn't deleted so it's still available from the point where development stopped publicly. I didn't build sagitta for while but it should work in theory (and can be fixed if it doesn't). Of course you need to build all packages yourself as described by this repo, the official method doesn't work since April 2024. You may also consider rolling if that fits your use-case. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! I let it run to completion and I got a Sagitta ISO. I installed it in a VM this morning and the few things that I had time to check all worked. I need to say that what you did here is brilliant! It's rare to find something on the internet that actually works exactly as documented and on the first try. |
Beta Was this translation helpful? Give feedback.
-
|
The VyOS Stream was released - https://vyos.net/get/stream/ The source code is given as 5gb tarball, it seem to contain quite a bit of irrelevant stuff since it contains more than thousand of source packages for stock Debian packages - I guess this is meant as the complete source code to achieve the exact same binary? Maybe... That's not relevant for us, we want up to date Debian packages anyway. Thus we care only about fraction of the sources. It's just bunch of source packages and generic tarballs, there is no additional information/build script. It's quite messy but I will later try to match the contents of the tarball to their github counterpart. The tarball contents (interesting part is the circinus and vyos-tarballs directory) |
Beta Was this translation helpful? Give feedback.
-
|
pefect,great news!!! |
Beta Was this translation helpful? Give feedback.
-
|
Trio build routine is here: |
Beta Was this translation helpful? Give feedback.
-
|
@Crushable1278 |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if you'd be open to adjusting the package.toml files to point to your repos, or perhaps adjusting the build script to have some "base repo/org" option that would essentially function as an override to sed github.com/vyos to another path (if it doesn't already have this). |
Beta Was this translation helpful? Give feedback.
-
|
Sure. Originally the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I guess some of you have seen the discussion we had in T6224 (yes not the best place, sorry about that), I knew the state of things is not good, but honestly had no idea it's really that bad... I have tried to stay reasonably calm, but still got so much hate for using VyOS in my "big" business (at home, actually two homes 3km apart with a 1Gbps microwave link between them, one where my parents live and I work and have one 10Gb fiber uplink there, and the other where I live with my wife and kids and have the other 800Mb microwave uplink) without subscription which I wouldn't be able to afford anyway (so they haven't lost any sales because of me) - if there was no way for me to get VyOS, I'd probably still be using EdgeOS (ERPro-8) + RouterOS (RB1100AH) without IPv6 which many of my competitors don't have either, and most of my customers don't care about anyway (PPPoE scales nicely, just add more servers, and the fastest one to respond gets the new session so it balances itself).
If we could get more people onboard (who also liked VyOS to be more open and more bazaar- not cathedral-style, but were cut off as "freeloaders" like us - maybe we could try to reach out to them somehow), maybe (just maybe, no high hopes, not sure if it succeeds, I know it's not easy) a community fork of VyOS (under a different name of course) could be made a reality. Even if it starts just as sagitta (current state of public repo) with strictly security fixes backported (part of which is already done by Debian, as we were lucky with RegreSSHion - though it's a bit puzzling why the recent Zabbix vulnerability is still unpatched - https://security-tracker.debian.org/tracker/CVE-2023-32728 -,it's not typical of Debian to take so long, I don't use Zabbix myself so haven't looked into it in more detail).
Again, not sure how likely this is to succeed, just dreaming... Having some former VyOS people onboard (which might happen if someone there is not 100% happy and told to leave - maybe not very likely, but not impossible either) could help us a lot to get started. This would probably require all repos to become independent (copies, not forks) of the original project.
VyOS (the software itself) is too good to die (or be bought out and become proprietary like Vyatta was), which I'm afraid might happen if some people don't become more friendly to the community - and I still try to not blame them, as I don't know them personally, someone could for example be a veteran with PTSD etc.
Just some thoughts...
Beta Was this translation helpful? Give feedback.
All reactions