Switzerland frontier with France have the less strong geographic barriers compered of the rest of the country's frontier. The Jura mountain chain is not height enough and there is large potion without any substantial elevation.
* You must own a 3D licence to drive it, witch cost you money and time to earn. * The instrument panel (because it's ugly to have useful information displayed all the time) will be replaced by a projection on the windshield with information placed everywhere on it as soon a you do an action, hiding the road. * And because there is too much informations there, there kill almost all of them as you should known yourself your actual speed (cpu load), energy reserve level (free memory), etc... * The commands around the steering wheel (because it's way too complicated for users) will be replaced by a touchpad on the center of the steering wheel: you have to swipe up to the extreme upper left corner to display the possible action catalog on the extreme right of the windshield projected screen and then swipe from the extreme left to the extreme right to select the action like turning on the light. Touchpad is the future, period. Commands are for the elders that can no longer adapt there brain to the modern evolution. * The navigation system (virtual desktop map) basically choose a random direction just second before intersection until it find the destination completely by luck. The map data randomly swap towns (desktop) location so you have to manually maintain a translation index in your head. You cannot program more than a few destinations. * There is no way to carry something other than a standardized adult on the car. Who would like to have children anyway ? And a car is only there for the joy of driving, so there is absolutely no need to have place for baggage or anything special to transport. Car have is not designed to transport something. * The car is only adapted to special roads made for them. Using it with previous generation of roads is completely unsupported can raise unexpected results. * All the accessories actually on the market are completely incompatible with this car. You have to use only the accessories provided by the manufacturer, but the catalog is very short and the quality is bad. * Sometime it cash for no reason. * The manufacturer of the car ignore any complain from there customers, telling to them that there are not using the car the way it was designed to be used.
Not really seeing much in the way of objective facts in your opinion piece.
The problem boils down to placing aesthetics above functionality
I guess that depends on what you mean by functional.
For me it mean working with a grid of 8*8 virtual desktops, with up to about 100 windows, and very fast way to switch between them. In work on a lot of projects and I never close my session so I can simply find a particular project exactly as it was last time I touched it. A project can take many desktops alone to fit all the required information (specification, search, edit, git, compilation, targets console, monitoring, chat, schematics, PCB, etc...)
Frankly, gnome is just a collection of current design trends that are questionable at best, and that is the reason you see the commentary.
So was Gnome 2 [...]
Last Gnome revision 2 was a climax for my workflow. Rock stable, and easy to configure to match my needs. Gnome 3 (and Unity by the way) is just a failed experiment that try to reinvent everything by simply denying decade of desktop usability work. It's a childish approach that was based from the beginning on the false idea that Gnome 2 was too complicated and also based on the even more false concept that nobody use a computer to do things more complex that what you can basically already do on a mobile phone.
Last Gnome 2 revision was the best desktop ever for professional use. It achieved the prodigious goal to be very simple for the beginners and very powerful for the most advanced users. It take literally a decade of work to produce last Gnome 2 with a lot of peoples involved on it. There all make very goods decisions to address the largest audience as possible. But this excluded the small audience of those that think that everyone must uses a gaming interface to just start a web browser in full screen like Gnome 3 do.
The Gnome project is now mismanaged by a team of blind revisionists that trashed a decade of good work. And the hegemony continue today with the lunch of "Software" that will only present and install applications coded by the same team of extremists. After having trashed the desktop concept there now try to trash the distribution concept. How a such catastrophe have taken place ?
Linux on the desktop faced a big opportunity with the Windows 8 change to the Metro interface that received a mixed reception. But it lost everything by replacing Gnome 2 by Gnome 3 or Unity. Linux on the desktop is now less usable than it was before.
I tried Gnome 3, Unity, KDE and now work with xfec4. It's not better than Gnome 2, but it's the one that provides the smallest regression compared to the others options. I need a very stable desktop (I never close by session) that support a lot of running application (about 100 at the same time) organized into a big virtual desktop grid (usually 8*8) and a very fast way to switch between them (without animation or need to click, only CTRL+arrow). I also need a lot of status from the hardware, a lot of small quick start icons, a taskbar and an applications menu well organized where I can read the full name of the executable. Sloppy focus, not raising windows on click, overlapped windows, and past with the middle mouse button are also mandatory for me.
I confess that I did't known that *BSD was also very advanced regarding the multiple ports support.
Multiarch is not an insane goal for a multiple of reasons. Technically is help to clean a lot of build problems in a proper way instead of a stack of quick hack. Pragmatically users often don't use only open source applications, and for this kind of application the architecture is a strong barrier. The ultimate goal of multiarch (witch is not fully completed yet) is to break this barrier: decoupling the processor architecture from the application architecture. This might sound useless for open source applications, but the reality is that a fair share of users like to use also non free applications. It also a bit of a philosophic view: should the OS impose to be supported by any applications, of should the OS be able to execute any applications ?
About architecture-portable code I almost completely share your point of view. Many new generation programmers dislike C and create even more difficult to maintain code in others (perceived as more advanced) languages. The C++ mangling out of any standard is the biggest failure ever in this regards, and there is not a single singe of a resolution for the foreseeable futures. There is GObject, but it require a relatively high level of skill. There is vala, but this is still a small curiosity in the language arena. There is Java, but it break almost everything when close to the kernel, relying more and more on his own API that is mostly imposed by commercial companies.
Actually it's a big deal: Debian is the only project on Earth that maintain so much architectures from the same code base and build system. There experience on that subject is outrageously ahead of many others projects. There have identified and implemented years before the others the need of a pure amd64 port (and not a quick/lib64 hack). There have adapted all there rules, and process to do that. There are now the only multiarch capable distribution. Many don't understand how complex it is to implement properly. It take something like 10 years, from the idea to the release.
If I understand you correctly, there are two type of failure: a definitive one and a temporary one. The definitive failure is very unlikely, so the longer warranty. The temporary failure could raise early and repeatedly, but very difficult to prove. This look like the bad sector problem on a HDD. As far as I know there is a similar mechanism used on SSD to mark bad region of a chip.
I have never see a warranty that protect the data in case of loss. The warranty only bring you a new device if the one you buy fail. You are lucky if the failed device is fixed instead of exchanged, as you might still found your data on it, but maybe not all coherent because of a failed transaction.
That won't work if they both die from some bug which is triggered by eg a certain write sequence followed by TRIM, then power cut in the middle of TRIM. They will both be killed.
Ok, but is this kind of systematic bug only theoretical or some finding tend to prove that there are a reality ?
Vous avez donc bien compris pourquoi je fais l'effort de vous parler en Anglais.
Since I have to quickly replace a defect machine, I go to the nearest PC shop, and there only have the "K" version in stock. The non-"K" would have show exactly the same result as I did't even tried to overclock the processor. I only used the BIOS default conservative configuration. I did not overclock the A10-6800K either. So this point is not a concern for this exchange.
Note: I never overclocked, but I sometimes underclock or limite the clock of a processors to stay into a comfortable thermal power range of a embedded system. I usually underclock my NFS servers too as my experience make me confident that it help a little to make them last longer, and there very rarely need a lot of processing power anyway.
English is a difficult task for me. Would you like to continue in french ?
My first concern was a new stable machine, not the price. If the price was a high concern I will have not even buy the i5-4670K in the first place. That said, I observe that a lower priced A10-6800K do the job just fine. Actually there is no processor on the Intel inventory that can match the GPU performance of the top AMD processors (and this is also true for discrete card as Intel don't make any of them). That might change in the future, but this fact is true as today.
Debian don't write drivers. You are ignorant if you pretend the contrary.
Are you award that Ubuntu is a Debian variation ? There uses exactly the same package management: apt and dpkg. I have tried Debian Sid without much success on the i5-4670K so backports will have not solved the problem anyway.
You can blame my decision if you like, you can blame Debian if you like. I think that expecting that a new machine work without trouble with the last new stable revision of one of the leading distribution is not so insane. I personally blame Intel for there overpriced processors with low end GPU, instable HDMI, and lack of support to Debian (after all there have far enough money to help a little). I have made a bad experience with Intel, no with you, so why are you so emotive ? My expectation was perfectly realist: the A10-6800K meet the goal very well for a lower price. That's so simple.
For me the price was CHF 252 for the i5-4670K and CHF 162 of the A10-6800K. Ok, it not twice the price, it's 55% more to be more exact. The DDR3 ram was the same and the motherboard price near identical.
I really owner a i5-4670K for two weeks. I have sold it this week-end to a young boy that will use it for gaming with an additional HD 8970 card.
I run Linux since 1995, I build embedded Linux system since 1999. I really prefer to run Debian stable on my main machine because I like the stability it granted to me since so many years. I have Ubuntu on a auxiliary machine, but it's not so stable and more and more filled by Ubuntu specific code, not counting the Unity interface that is so unproductive when you have to manage many applications.
So the goal for me was simple: buying a new main machine that will work on Debian stable. The i5-4670K failed, the A10-6800K succeeded. Try by yourself if you don't trust me.
First, I never insulted you. I just share my experience. I am not a liar. Two weeks ago my 5 years old main machine motherboard failed and I needed a new one quickly to finish my work. My nearest PC shop have not so many parts in stock, some underpowered AMD processors and only a few mid to high end Intel processors. This is why I end up with the i5-4670K. I used it a few days with the configuration of my old machine as I have no time left. So I worked without sound, video, or 3D, and with some display glitch, a few per day that last just a second but I never observer this before. One week ago I take time trying to fix the configuration. I tried many new install, loosing a lot of time, without reaching a fully working setup. So I ordered the A10-6800K for testing. It was shipped last Friday and to my surprise it worked fairly well on the first try, using open source video driver. I added the fglrx driver and the result was simply perfect.
The i5-4670K was CHF 252.00 and the A10-6800K was CHF 162.00. So, ok this is not half the price out of the shop, I concede this. But if I count the hours passed on each setup, and the final result, the A10-6800K is a clear winner to me: lower price + shorter time + better result.
As for your morality, keep in mind who have invested first in 64 bit x86 architecture, integrated memory controller, integrated multiple core, and integrated GPU while under the attack of a bigger concurrent that have payed a really impressive transaction to close the case a few years latter.
The A10-6800K was released the same month as the i5-4670K: june 2013, so there the two equally brand new hardware. I have tested last week without success the Debian Sid on the i5-4670K. Can't repeat the experience this week as I have sold it. And I doubt that the distro was the cause of the HDMI instability.
Why I will pay more for a CPU and pay for an additional GPU card to get what I can get with a APU for half the price of the CPU ? Oh and this GPU card will probably need a closed source driver anyway.
Ok, the Debian Wheezy argument is a bit off tropic out of my concern. But still, compared to the A10-6800K, the i5-4670K is not the nirvana: * The HDMI output was not stable. * The GPU performance was way inferior. * The price was twice.
I just sold my almost new i5-4670K to replace it by a A10-6800K. With the i5, it's simply impossible to get a working machine by using the new Debian Wheezy: no audio, no accelerated 3D, no fluid video, screen instability on the HDMI output, and high price. On the contrary, the A10 work perfectly well: audio, accelerated 3D, glitch free 1080p full screen video, rock stable HDMI output, and half of the i5 price.
Humm... Once upon a time Intel was saying very similar claim about the AMD64 architecture asserting that there own 64bits architecture will rule the market in a few years anyway. Today I can't even remember the name of that Intel architecture, but all my PCs and servers runs AMD64 distributions.
Don't compare the raspberry pi obsolete armv6k architecture, that is bored to support from a distribution point of view, to the new arm64 architecture that will without any doubt gain a very large support in the future. The machine specific code will be limited to the kernel. Linus expectation about the arm* architectures will ensure that this will be integrated in a fare better way than it used to be in the past.
ARM was really not designed from the start to be a coherent ecosystem targeted to run a standardized operating system. The fragmentation only reflect that and the fact that there is a very high financial motivation to run Linux on that chips. Nobody are really happy about the current arm SoC fragmentation. Even the SoC designer are not completely immune to the critics of the kernel developers. If a chip can be tested more quickly by using already available driver, the hardware engineers hare happy too. So expect a big reset/reload on that subject for the arm64 architecture.
... but ARM ain't about to take over the server room at this pace.
For servers that run distributions that will have a good quality arm64 port, the transition could be as easy as the transition from i386 to amd64 architecture. Linaro, Debian and Ubuntu seem to work to make this a reality as soon as the hardware hit the market (and maybe even before for Linaro). Don't known for Fedora, but there will certainly not miss the opportunity.
Slashdot Mirror
Switzerland frontier with France have the less strong geographic barriers compered of the rest of the country's frontier. The Jura mountain chain is not height enough and there is large potion without any substantial elevation.
While your claim could be technically true, the actual user experience is far below the Gnome 2 level.
* You must own a 3D licence to drive it, witch cost you money and time to earn.
* The instrument panel (because it's ugly to have useful information displayed all the time) will be replaced by a projection on the windshield with information placed everywhere on it as soon a you do an action, hiding the road.
* And because there is too much informations there, there kill almost all of them as you should known yourself your actual speed (cpu load), energy reserve level (free memory), etc...
* The commands around the steering wheel (because it's way too complicated for users) will be replaced by a touchpad on the center of the steering wheel: you have to swipe up to the extreme upper left corner to display the possible action catalog on the extreme right of the windshield projected screen and then swipe from the extreme left to the extreme right to select the action like turning on the light. Touchpad is the future, period. Commands are for the elders that can no longer adapt there brain to the modern evolution.
* The navigation system (virtual desktop map) basically choose a random direction just second before intersection until it find the destination completely by luck. The map data randomly swap towns (desktop) location so you have to manually maintain a translation index in your head. You cannot program more than a few destinations.
* There is no way to carry something other than a standardized adult on the car. Who would like to have children anyway ? And a car is only there for the joy of driving, so there is absolutely no need to have place for baggage or anything special to transport. Car have is not designed to transport something.
* The car is only adapted to special roads made for them. Using it with previous generation of roads is completely unsupported can raise unexpected results.
* All the accessories actually on the market are completely incompatible with this car. You have to use only the accessories provided by the manufacturer, but the catalog is very short and the quality is bad.
* Sometime it cash for no reason.
* The manufacturer of the car ignore any complain from there customers, telling to them that there are not using the car the way it was designed to be used.
Not really seeing much in the way of objective facts in your opinion piece.
The problem boils down to placing aesthetics above functionality
I guess that depends on what you mean by functional.
For me it mean working with a grid of 8*8 virtual desktops, with up to about 100 windows, and very fast way to switch between them. In work on a lot of projects and I never close my session so I can simply find a particular project exactly as it was last time I touched it. A project can take many desktops alone to fit all the required information (specification, search, edit, git, compilation, targets console, monitoring, chat, schematics, PCB, etc...)
Frankly, gnome is just a collection of current design trends that are questionable at best, and that is the reason you see the commentary.
So was Gnome 2 [...]
Last Gnome revision 2 was a climax for my workflow. Rock stable, and easy to configure to match my needs. Gnome 3 (and Unity by the way) is just a failed experiment that try to reinvent everything by simply denying decade of desktop usability work. It's a childish approach that was based from the beginning on the false idea that Gnome 2 was too complicated and also based on the even more false concept that nobody use a computer to do things more complex that what you can basically already do on a mobile phone.
Last Gnome 2 revision was the best desktop ever for professional use. It achieved the prodigious goal to be very simple for the beginners and very powerful for the most advanced users. It take literally a decade of work to produce last Gnome 2 with a lot of peoples involved on it. There all make very goods decisions to address the largest audience as possible. But this excluded the small audience of those that think that everyone must uses a gaming interface to just start a web browser in full screen like Gnome 3 do.
The Gnome project is now mismanaged by a team of blind revisionists that trashed a decade of good work. And the hegemony continue today with the lunch of "Software" that will only present and install applications coded by the same team of extremists. After having trashed the desktop concept there now try to trash the distribution concept. How a such catastrophe have taken place ?
Lens
Linux on the desktop faced a big opportunity with the Windows 8 change to the Metro interface that received a mixed reception. But it lost everything by replacing Gnome 2 by Gnome 3 or Unity. Linux on the desktop is now less usable than it was before.
I tried Gnome 3, Unity, KDE and now work with xfec4. It's not better than Gnome 2, but it's the one that provides the smallest regression compared to the others options. I need a very stable desktop (I never close by session) that support a lot of running application (about 100 at the same time) organized into a big virtual desktop grid (usually 8*8) and a very fast way to switch between them (without animation or need to click, only CTRL+arrow). I also need a lot of status from the hardware, a lot of small quick start icons, a taskbar and an applications menu well organized where I can read the full name of the executable. Sloppy focus, not raising windows on click, overlapped windows, and past with the middle mouse button are also mandatory for me.
Your home router probably run Linux too.
I confess that I did't known that *BSD was also very advanced regarding the multiple ports support.
Multiarch is not an insane goal for a multiple of reasons. Technically is help to clean a lot of build problems in a proper way instead of a stack of quick hack. Pragmatically users often don't use only open source applications, and for this kind of application the architecture is a strong barrier. The ultimate goal of multiarch (witch is not fully completed yet) is to break this barrier: decoupling the processor architecture from the application architecture. This might sound useless for open source applications, but the reality is that a fair share of users like to use also non free applications. It also a bit of a philosophic view: should the OS impose to be supported by any applications, of should the OS be able to execute any applications ?
About architecture-portable code I almost completely share your point of view. Many new generation programmers dislike C and create even more difficult to maintain code in others (perceived as more advanced) languages. The C++ mangling out of any standard is the biggest failure ever in this regards, and there is not a single singe of a resolution for the foreseeable futures. There is GObject, but it require a relatively high level of skill. There is vala, but this is still a small curiosity in the language arena. There is Java, but it break almost everything when close to the kernel, relying more and more on his own API that is mostly imposed by commercial companies.
Actually it's a big deal: Debian is the only project on Earth that maintain so much architectures from the same code base and build system. There experience on that subject is outrageously ahead of many others projects. There have identified and implemented years before the others the need of a pure amd64 port (and not a quick /lib64 hack). There have adapted all there rules, and process to do that. There are now the only multiarch capable distribution. Many don't understand how complex it is to implement properly. It take something like 10 years, from the idea to the release.
If I understand you correctly, there are two type of failure: a definitive one and a temporary one.
The definitive failure is very unlikely, so the longer warranty.
The temporary failure could raise early and repeatedly, but very difficult to prove.
This look like the bad sector problem on a HDD. As far as I know there is a similar mechanism used on SSD to mark bad region of a chip.
I have never see a warranty that protect the data in case of loss. The warranty only bring you a new device if the one you buy fail. You are lucky if the failed device is fixed instead of exchanged, as you might still found your data on it, but maybe not all coherent because of a failed transaction.
That won't work if they both die from some bug which is triggered by eg a certain write sequence followed by TRIM, then power cut in the middle of TRIM. They will both be killed.
Ok, but is this kind of systematic bug only theoretical or some finding tend to prove that there are a reality ?
Vous avez donc bien compris pourquoi je fais l'effort de vous parler en Anglais.
Since I have to quickly replace a defect machine, I go to the nearest PC shop, and there only have the "K" version in stock. The non-"K" would have show exactly the same result as I did't even tried to overclock the processor. I only used the BIOS default conservative configuration. I did not overclock the A10-6800K either. So this point is not a concern for this exchange.
Note: I never overclocked, but I sometimes underclock or limite the clock of a processors to stay into a comfortable thermal power range of a embedded system. I usually underclock my NFS servers too as my experience make me confident that it help a little to make them last longer, and there very rarely need a lot of processing power anyway.
English is a difficult task for me. Would you like to continue in french ?
My first concern was a new stable machine, not the price. If the price was a high concern I will have not even buy the i5-4670K in the first place. That said, I observe that a lower priced A10-6800K do the job just fine. Actually there is no processor on the Intel inventory that can match the GPU performance of the top AMD processors (and this is also true for discrete card as Intel don't make any of them). That might change in the future, but this fact is true as today.
Debian don't write drivers. You are ignorant if you pretend the contrary.
Are you award that Ubuntu is a Debian variation ? There uses exactly the same package management: apt and dpkg. I have tried Debian Sid without much success on the i5-4670K so backports will have not solved the problem anyway.
You can blame my decision if you like, you can blame Debian if you like. I think that expecting that a new machine work without trouble with the last new stable revision of one of the leading distribution is not so insane. I personally blame Intel for there overpriced processors with low end GPU, instable HDMI, and lack of support to Debian (after all there have far enough money to help a little). I have made a bad experience with Intel, no with you, so why are you so emotive ? My expectation was perfectly realist: the A10-6800K meet the goal very well for a lower price. That's so simple.
For me the price was CHF 252 for the i5-4670K and CHF 162 of the A10-6800K. Ok, it not twice the price, it's 55% more to be more exact. The DDR3 ram was the same and the motherboard price near identical.
I really owner a i5-4670K for two weeks. I have sold it this week-end to a young boy that will use it for gaming with an additional HD 8970 card.
I run Linux since 1995, I build embedded Linux system since 1999. I really prefer to run Debian stable on my main machine because I like the stability it granted to me since so many years. I have Ubuntu on a auxiliary machine, but it's not so stable and more and more filled by Ubuntu specific code, not counting the Unity interface that is so unproductive when you have to manage many applications.
So the goal for me was simple: buying a new main machine that will work on Debian stable. The i5-4670K failed, the A10-6800K succeeded. Try by yourself if you don't trust me.
First, I never insulted you. I just share my experience. I am not a liar. Two weeks ago my 5 years old main machine motherboard failed and I needed a new one quickly to finish my work. My nearest PC shop have not so many parts in stock, some underpowered AMD processors and only a few mid to high end Intel processors. This is why I end up with the i5-4670K. I used it a few days with the configuration of my old machine as I have no time left. So I worked without sound, video, or 3D, and with some display glitch, a few per day that last just a second but I never observer this before. One week ago I take time trying to fix the configuration. I tried many new install, loosing a lot of time, without reaching a fully working setup. So I ordered the A10-6800K for testing. It was shipped last Friday and to my surprise it worked fairly well on the first try, using open source video driver. I added the fglrx driver and the result was simply perfect.
The i5-4670K was CHF 252.00 and the A10-6800K was CHF 162.00. So, ok this is not half the price out of the shop, I concede this. But if I count the hours passed on each setup, and the final result, the A10-6800K is a clear winner to me: lower price + shorter time + better result.
As for your morality, keep in mind who have invested first in 64 bit x86 architecture, integrated memory controller, integrated multiple core, and integrated GPU while under the attack of a bigger concurrent that have payed a really impressive transaction to close the case a few years latter.
The A10-6800K was released the same month as the i5-4670K: june 2013, so there the two equally brand new hardware.
I have tested last week without success the Debian Sid on the i5-4670K. Can't repeat the experience this week as I have sold it.
And I doubt that the distro was the cause of the HDMI instability.
Why I will pay more for a CPU and pay for an additional GPU card to get what I can get with a APU for half the price of the CPU ? Oh and this GPU card will probably need a closed source driver anyway.
Ok, the Debian Wheezy argument is a bit off tropic out of my concern.
But still, compared to the A10-6800K, the i5-4670K is not the nirvana:
* The HDMI output was not stable.
* The GPU performance was way inferior.
* The price was twice.
Still twice the price compared to the A10, even using Arch Linux...
Mod parent up.
I just sold my almost new i5-4670K to replace it by a A10-6800K. With the i5, it's simply impossible to get a working machine by using the new Debian Wheezy: no audio, no accelerated 3D, no fluid video, screen instability on the HDMI output, and high price. On the contrary, the A10 work perfectly well: audio, accelerated 3D, glitch free 1080p full screen video, rock stable HDMI output, and half of the i5 price.
Humm... Once upon a time Intel was saying very similar claim about the AMD64 architecture asserting that there own 64bits architecture will rule the market in a few years anyway. Today I can't even remember the name of that Intel architecture, but all my PCs and servers runs AMD64 distributions.
Don't compare the raspberry pi obsolete armv6k architecture, that is bored to support from a distribution point of view, to the new arm64 architecture that will without any doubt gain a very large support in the future. The machine specific code will be limited to the kernel. Linus expectation about the arm* architectures will ensure that this will be integrated in a fare better way than it used to be in the past.
ARM was really not designed from the start to be a coherent ecosystem targeted to run a standardized operating system. The fragmentation only reflect that and the fact that there is a very high financial motivation to run Linux on that chips. Nobody are really happy about the current arm SoC fragmentation. Even the SoC designer are not completely immune to the critics of the kernel developers. If a chip can be tested more quickly by using already available driver, the hardware engineers hare happy too. So expect a big reset/reload on that subject for the arm64 architecture.
... but ARM ain't about to take over the server room at this pace.
For servers that run distributions that will have a good quality arm64 port, the transition could be as easy as the transition from i386 to amd64 architecture. Linaro, Debian and Ubuntu seem to work to make this a reality as soon as the hardware hit the market (and maybe even before for Linaro). Don't known for Fedora, but there will certainly not miss the opportunity.