Ben Holmes wrote:
I wonder how many packages *really* benefit (that is, enough to warrant keeping them) from v3/v4 instructions?
well the issue thats got my attention is on one hand there saying a move to v2 but at the same time saying the performance benifits are with v3 , at the same time though removing v0 /v1 hardware in favour of v2 is not gong to provide the performance increase to v3/v4 users making the whole issue rather pointless and putting a vast number of users in a position they need new hardware , it maybe fine for redhat to go this route since they market for new machines and business users (dell for example provides redhat as a o/s option on new machines ) but tumbleweed is mostly home/hobby use and most installs i suspect are on ex lease kit or self builds , its not fair on users to be left out because the cpu gets removed from the current versions , so although i see the need to provide more optimised code for newer cpus there dose need to be provision to suport the other cpus , the first most users will know is when they do there weekly zapper -dup , and reboot to find there machine is no longer supported , not that it will tell them why its not running , not that some will know what x86_64 vX means, but this also needs to be avoided , at the same time implimenting the v0,1,2,3,4,n version system now would allow not just v2 optimised code , but allow for v3 and 4 optimised code to be introduced then and only then (by looking at actual server download logs) will you see for shure if removing v0, or v1 is going to affect the user base practicaly its should not be hard to impliment eather a xvx sufix or i86_64_x(n) sufix and provide zypper support for that just like the whole x86_32 to x86_64 issue this has been brewing for some time , but untill now its just been left at the same time its posible to impliment it so it choses the best version to suit the chipset and update say a v0 to v2 even to v3 or v4 as the binaries are added to the servers the issue i think is ether server space , given the extra binarys needed , or workload of the compile farm for producing those binaries , (could we get an answer on this ?) by the sounds of it unless there is an advantage performance wise there should be no need to produce a v2 version of code over a v0 - v1 version , but there is more a need to provide a v3 version in some cases , and maybe in others a v4 also while still providing lower version support if this is not resolved now then i suspect it wont be too long before v2 gets dropped in favor of v3, for the same reasons users will not forget and swich distros to ones that do still support there hardware , if you dont know how many users then i would be cautious sorry to ramble on about it , but i know of a number of users that will end up with no machine to use after the switch to v2 minimum when it trickles down to tumbleweed , with no way to afford newer machines and no idea what they would need to get (second hand) if they could afford to , let alone be in a position to know that this is comming untill it does , probabaly account for about 5 to 10 machines made into e waste on that update, just on a small number of users i know of, and about 4 machines of my own (that i may of been able to hand down to them to help , other than there also going to be unsuported ) rather it only highlights the lack of actual performance increases there have been in the last 20 years, and "bricking " v0-v1 cpus for only marganal performance advantages is not going to be looked on kindly by the community that is mostly using legacy hardware of that type, and at the same time not providing the v3 and v4 optimisations is not going to be taken lightly by those that do have such cpus and are not seeing any gains