On Linux I am forced to include everything including the kitchen sink out of necessity because it's the only way to guarantee my software will work properly across the most number of distros and configurations of Linux.
My build system simply builds packages 'natively' for each of the distributions (rpms, debs). I don't have to bundle everything and the install experience is painless to the users. Meanwhile software developed and distributed as a binary tar.gz that includes all kinds of libraries mean you go your own way with things like openssl and I don't want to deal with updating it or trusting you to keep it updated.
I have VMs across distros dating back nearly two decades and virtually none of them even newer Linux distros only a few years old can install or update software because the repositories for these versions have been long since pulled.
If a user does something like selects Fedora 16 and fails to migrate, then you should not feel any need to help them. They should know there are specific distributions designed for that (rhel, suse, centos).
If you're a hardware vendor the one and only chance you have is getting your code into mainline AND waiting for it to filter down into all distros which can take years because there is no usable pluggable driver model for Linux
There's some truth to this, though mitigated through targeting the 'enterprise' distributions and also mitigated by sticking to standards in USB or bluetooth for at least those devices. Under windows even I don't see most accessories having drivers these days. PCIe adapters of course still have to contend with this...
Case in point the other day suffered a single disk failure in intel fakeraid RAID1.
Intel RST is crap and it's all Intel's fault. Intel chose to do the worst of both worlds by using the software raid, but then horribly restricting it...
I'd love people wanting to enrich my documentation when I don't have anyone else and my documentation comes from my own hand which has no context of 'new to the software'.
A problem I have faced when I did get multiple documentation contributors is that they'll sometimes just keep rewriting each other's stuff back and forth, as they have a difference in opinion on how to be more clear. Ultimately, a side is going to be selected and someone will be unhappy.
But in the browser, if there's an extension, I don't know, but you can hit ctrl-shift-c, click the video, then go up to the element for div id 'player': div id="player"...
And then after selecting that, add to the 'element.style' section on the right: position: fixed width: 100% z-index: 1000
And the player will no longer scroll with the page.
I imagine an extension to detect the page and modify the css would be easy to make...
There's of course a lot of subjective going on here, but...
To me wide screen is more comfortable. It's how my vision naturally works. Field of view is wider than it is tall. The one case I'll pivot my screen for is a word doc or PDF, because it won't wrap lines for wider formats (well in Word I *could* change the page layout, but it's a crapshoot with many documents because they are particular about the layout). Occasionally a web page will go nuts with the CSS to get that 'print' feel and waste a lot of screen in wide format, so that too will have me pivot a screen for the content.
I suspect print gravitated toward portrait to accommodate being held in one hand better. Fixed screens don't have that problem, so widescreen dominated.
Then came phones. Once again the comfort of balancing portrait wins over landscape.
Software development time is far from a fungible thing. If I redirected some of my time to, say, going to synthesize vaccines, well I'd produce less software but I'd probably produce no vaccines in my attempt. Economy is our best approximation for equating value of different things, but at the end of the day there are differences that don't work.
Sure, volunteer as you can, this is a worthy and honorable thing t odo. However you can't volunteer all the time. Even as you attempt to volunteer to feed the hungry, you may be turned away because they have enough volunteers. Produce vegetables, sure, that no one will want because there are already plenty of vegetables supplied. Raise chickens and do more harm than good as you end up giving people salmonella. It's frequently not so trivial to convert 'guy thinking and pressing keys on a keyboard' to 'saving children'.
Similar boat. Pidgin-sipe does let me interact with Skype 4 Business, but the microphone volume management and had to rebuild to get the right codecs, so it's far from baked to get to same quality, but it is serviceable.
Also pidgin UI isn't quite as well geared as Skype 4 Business gui for doing 'buddy-less' communication, and selecting audio device is clunkier...
But everything else is effortless and smooth and no 'fudging about with source code' or stuff like that (unless I want to) outside of trying to get an acceptable S4B experience using native Linux stuff.
I don't even resort to Wine, just linux applications for everything.
I doubt the time of these hobbyists would have saved at least a dozen children. Just like the resources and effort to make a single Lamborghini cannot be directly used to create 10 honda accords, despite the price tag suggesting that would be the case given a simplistic interpretation of 'value'.
The critical assessment could also have applied to Linux in 1993, this silly unusable Unix-wannabe, what's the point, we have several Unix vendors alreday? Linus himself said "I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones". It's hard for me to picture this scenario for ReactOS of course, but it is a good thing that sort of assessment didn't discourage free software back then...
Also value in preservation, if not practical direct use. In this marvelous age where we have created the ability to have perfect preservation in terms of digital data, we do a lot to make it still unlikely to run old software. Efforts like FreeDOS and ReactOS improve chances of preserving experience of 'dead' platform/platform revisions.
Or having the TPM/Enclave protected key with reasonably usable or no passphrase required to boot if present, and a recovery password, which is much slower to access absent of the TPM (e.g. an ungodly number of ronuds of KDF).
Well, here it's a bit of an evolved situation, and one that evolved with the general state of storage.
Once upon a time, OSes didn't bother to cache writes, they just wrote to disk and were done. Computer could just turn off at any time (parking hard drives manually aside). Memory was too scarce.
Then memory was more plentiful and OSes became more sophisticated, disk IO then presumed caching, and shutting off your system without proper shutdown was exceedingly high risk. Removable media came into fashion with this sort of accepted behavior, so they had to be very verbose about users doing it wrong.
Fast forward a bit and the industry realizes that they can't expect clean ejects/shutdowns, so they make better filesystems, maybe losing data but at least not be corrupted and disable write cache on usb disks by default, causing slower apparent behavior, but resilient to yanking out.
It's always a good idea to err on the side of caution, but the current OS designs around ejecting media are less critical because they've decided it is a lost cause.
Because adding a button and indicator to show completion means cost and ruining the 'minimalist' design point they are going for. Further, they know consumers will likely ignore that anyway, and that OSes have given up write-caching for removable storage anyway.
Err on the side of caution. Etiher: You don't need to because the system isn't caching writes, in which case the result is instant The result is slow, which means you need to do the 'eject' procedure. Practically speaking, modern OSes have gotten the point, a small usb attached storage device is at high risk to be yanked out, so they disable write caching by default.
Docker is not running software on other distros, it's running it on the same distro.
It is of course a fair point that the ecosystem and capabilities of Linux lend itself better to container approaches, but the technical reality is that the approach is a workwround for the problem, rather than addressing the problem.
Of course, here the 'problem' is that developers need to target the oldest version they should support, which isn't too terrible.
A *shell* as a snap seems to be an odd choice. It should be embedded in whatever environment.
Powershell doesn't make sense as an end in and of itself, and 'Snap' and similar strategies only really possibly make sense for software that is an end in and of itself...
At layer 2, the promise of value is more granular control over packet forwarding than designating vlans.
The switch chips under the covers have a great deal of impossibly complicated capabilities that traditional switch config software abstracts away to basically vlan and not much else. Traditionally there is also sometimes helpful filtering (e.g. 'do not forward ethernet frame if it's dhcp response'), though that is a bit rare and generally hard to configure. There exists a contingent of folks who want to go deeper and imagine higher performance topology (e.g. a fat tree, torus, dragonfly, basically the sorts of topologies you see in infiniband and omnipath) that spanning tree would spit all over, and MST or similar would be too coarse. TRILL was the 'non-SDN' answer proposed to provide other topologies on ethernet, but that didn't pan out.
Problem is that in practice, it's trying to reinvent the infiniband sort of strategy (openflow controller is like an infiniband subnet manager) and this is very difficult to pull off, and generally superfluous for most people and the rest could... just get infiniband where the solution is pretty mature....
For example, a lot of very large internet datacenters have extraordinarily convoluted networking configuration, which is fine if you have expertise and need the power, but broadly speaking most don't need that power but they do need simplicity.
They might have decided their equipment works best with small broadcast domains and just focus on layer 3 technologies, but a shop may have been doing just fine with their oversized broadcast domain because their network vendor made the most of that sort of topology rather than skipping it because it's a bad idea.
Well, I was assuming the parent was joking, that it could be software all the way down, which isn't obviously possible.
In terms of software defined switches, generally speaking they consider any switch that can be ONIE to be 'SDN-friendly', and some others.Sure, there are switching chips doing the actual moving of the data (there pretty much has to be), but their primitive capabilities are exposed to software for more in depth wrangling.
In practice though the complexity of SDN switching is well beyond the point of diminishing returns for almost everywhere to bother with.
I'm with you there. Some things the camera wouldn't be able to capture that was being bragged about (different planes of focus, though this is something I personally haven't been bothered by in my VR experience).
Either way, being *way* later to market and seemingly no better than the 'lame' AR already there does not seem like it was worth the investment..
Two disappointments from the video: latency (the rock reacts to the hand well after the hand was there) and the translucency (everything is 'ghosty', a persistent problem for AR to present 'real' seeming things).
However, it did seem to do a serviceable job with fixed hard surfaces (floor and wall) and would probably be good enough to do the 'whale out of the floor' animation.
Slashdot Mirror
I will agree with this, the lesson is not to avoid Linux for RAID, it's to avoid Intel RST(e) in all it's forms.
You want hardware raid? Go with PMC, Broadcom/Avago/LSI.
You want to use the cheap integrated Intel storage chip with RAID? Use software raid and do not dirty it by trying to use the 'RST'-compatible hacks.
On Linux I am forced to include everything including the kitchen sink out of necessity because it's the only way to guarantee my software will work properly across the most number of distros and configurations of Linux.
My build system simply builds packages 'natively' for each of the distributions (rpms, debs). I don't have to bundle everything and the install experience is painless to the users. Meanwhile software developed and distributed as a binary tar.gz that includes all kinds of libraries mean you go your own way with things like openssl and I don't want to deal with updating it or trusting you to keep it updated.
I have VMs across distros dating back nearly two decades and virtually none of them even newer Linux distros only a few years old can install or update software because the repositories for these versions have been long since pulled.
If a user does something like selects Fedora 16 and fails to migrate, then you should not feel any need to help them. They should know there are specific distributions designed for that (rhel, suse, centos).
If you're a hardware vendor the one and only chance you have is getting your code into mainline AND waiting for it to filter down into all distros which can take years because there is no usable pluggable driver model for Linux
There's some truth to this, though mitigated through targeting the 'enterprise' distributions and also mitigated by sticking to standards in USB or bluetooth for at least those devices. Under windows even I don't see most accessories having drivers these days. PCIe adapters of course still have to contend with this...
Case in point the other day suffered a single disk failure in intel fakeraid RAID1.
Intel RST is crap and it's all Intel's fault. Intel chose to do the worst of both worlds by using the software raid, but then horribly restricting it...
I'd love people wanting to enrich my documentation when I don't have anyone else and my documentation comes from my own hand which has no context of 'new to the software'.
A problem I have faced when I did get multiple documentation contributors is that they'll sometimes just keep rewriting each other's stuff back and forth, as they have a difference in opinion on how to be more clear. Ultimately, a side is going to be selected and someone will be unhappy.
I have two current consoles and I pay no monthly fee...
I also don't even look at a game if there is a monthly fee associated with it.
Well, they do it in mobile...
But in the browser, if there's an extension, I don't know, but you can hit ctrl-shift-c, click the video, then go up to the element for div id 'player':
div id="player"...
And then after selecting that, add to the 'element.style' section on the right:
position: fixed
width: 100%
z-index: 1000
And the player will no longer scroll with the page.
I imagine an extension to detect the page and modify the css would be easy to make...
Because we do not only consume content from a phone.
When we are not worried about the awkwardness of trying to hold a phone wide with one hand, wide format is more like the way our normal vision works.
Generally speaking we do not tilt our head sideways to make our natural view 'portrait'.
This is why I miss media keys working. Web ecosystem seems to not care about doing anything to enable those once useful, but mostly neglected keys...
There's of course a lot of subjective going on here, but...
To me wide screen is more comfortable. It's how my vision naturally works. Field of view is wider than it is tall. The one case I'll pivot my screen for is a word doc or PDF, because it won't wrap lines for wider formats (well in Word I *could* change the page layout, but it's a crapshoot with many documents because they are particular about the layout). Occasionally a web page will go nuts with the CSS to get that 'print' feel and waste a lot of screen in wide format, so that too will have me pivot a screen for the content.
I suspect print gravitated toward portrait to accommodate being held in one hand better. Fixed screens don't have that problem, so widescreen dominated.
Then came phones. Once again the comfort of balancing portrait wins over landscape.
Time is money and resources etc
Software development time is far from a fungible thing. If I redirected some of my time to, say, going to synthesize vaccines, well I'd produce less software but I'd probably produce no vaccines in my attempt. Economy is our best approximation for equating value of different things, but at the end of the day there are differences that don't work.
Sure, volunteer as you can, this is a worthy and honorable thing t odo. However you can't volunteer all the time. Even as you attempt to volunteer to feed the hungry, you may be turned away because they have enough volunteers. Produce vegetables, sure, that no one will want because there are already plenty of vegetables supplied. Raise chickens and do more harm than good as you end up giving people salmonella. It's frequently not so trivial to convert 'guy thinking and pressing keys on a keyboard' to 'saving children'.
Similar boat. Pidgin-sipe does let me interact with Skype 4 Business, but the microphone volume management and had to rebuild to get the right codecs, so it's far from baked to get to same quality, but it is serviceable.
Also pidgin UI isn't quite as well geared as Skype 4 Business gui for doing 'buddy-less' communication, and selecting audio device is clunkier...
But everything else is effortless and smooth and no 'fudging about with source code' or stuff like that (unless I want to) outside of trying to get an acceptable S4B experience using native Linux stuff.
I don't even resort to Wine, just linux applications for everything.
I doubt the time of these hobbyists would have saved at least a dozen children. Just like the resources and effort to make a single Lamborghini cannot be directly used to create 10 honda accords, despite the price tag suggesting that would be the case given a simplistic interpretation of 'value'.
The critical assessment could also have applied to Linux in 1993, this silly unusable Unix-wannabe, what's the point, we have several Unix vendors alreday? Linus himself said "I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones". It's hard for me to picture this scenario for ReactOS of course, but it is a good thing that sort of assessment didn't discourage free software back then...
Also value in preservation, if not practical direct use. In this marvelous age where we have created the ability to have perfect preservation in terms of digital data, we do a lot to make it still unlikely to run old software. Efforts like FreeDOS and ReactOS improve chances of preserving experience of 'dead' platform/platform revisions.
Or having the TPM/Enclave protected key with reasonably usable or no passphrase required to boot if present, and a recovery password, which is much slower to access absent of the TPM (e.g. an ungodly number of ronuds of KDF).
Well, here it's a bit of an evolved situation, and one that evolved with the general state of storage.
Once upon a time, OSes didn't bother to cache writes, they just wrote to disk and were done. Computer could just turn off at any time (parking hard drives manually aside). Memory was too scarce.
Then memory was more plentiful and OSes became more sophisticated, disk IO then presumed caching, and shutting off your system without proper shutdown was exceedingly high risk. Removable media came into fashion with this sort of accepted behavior, so they had to be very verbose about users doing it wrong.
Fast forward a bit and the industry realizes that they can't expect clean ejects/shutdowns, so they make better filesystems, maybe losing data but at least not be corrupted and disable write cache on usb disks by default, causing slower apparent behavior, but resilient to yanking out.
It's always a good idea to err on the side of caution, but the current OS designs around ejecting media are less critical because they've decided it is a lost cause.
Because adding a button and indicator to show completion means cost and ruining the 'minimalist' design point they are going for. Further, they know consumers will likely ignore that anyway, and that OSes have given up write-caching for removable storage anyway.
Err on the side of caution. Etiher:
You don't need to because the system isn't caching writes, in which case the result is instant
The result is slow, which means you need to do the 'eject' procedure.
Practically speaking, modern OSes have gotten the point, a small usb attached storage device is at high risk to be yanked out, so they disable write caching by default.
Docker is not running software on other distros, it's running it on the same distro.
It is of course a fair point that the ecosystem and capabilities of Linux lend itself better to container approaches, but the technical reality is that the approach is a workwround for the problem, rather than addressing the problem.
Of course, here the 'problem' is that developers need to target the oldest version they should support, which isn't too terrible.
A *shell* as a snap seems to be an odd choice. It should be embedded in whatever environment.
Powershell doesn't make sense as an end in and of itself, and 'Snap' and similar strategies only really possibly make sense for software that is an end in and of itself...
Well, if you build for Ubuntu 18.04 and then try to run on say RHEL6, then you are going to have fundamental challenges.
However, if you build RHEL6, then generally that executable can run on Ubuntu 18.04, so a build system should target the oldest you want to support.
This can also trip you up with Windows, but the releases are so infrequent by comparison that people don't notice it as much.
Not a simile, he means it is useless when trying to consider it as a QC.
At layer 2, the promise of value is more granular control over packet forwarding than designating vlans.
The switch chips under the covers have a great deal of impossibly complicated capabilities that traditional switch config software abstracts away to basically vlan and not much else. Traditionally there is also sometimes helpful filtering (e.g. 'do not forward ethernet frame if it's dhcp response'), though that is a bit rare and generally hard to configure. There exists a contingent of folks who want to go deeper and imagine higher performance topology (e.g. a fat tree, torus, dragonfly, basically the sorts of topologies you see in infiniband and omnipath) that spanning tree would spit all over, and MST or similar would be too coarse. TRILL was the 'non-SDN' answer proposed to provide other topologies on ethernet, but that didn't pan out.
Problem is that in practice, it's trying to reinvent the infiniband sort of strategy (openflow controller is like an infiniband subnet manager) and this is very difficult to pull off, and generally superfluous for most people and the rest could... just get infiniband where the solution is pretty mature....
'Bigger' is not the only metric.
For example, a lot of very large internet datacenters have extraordinarily convoluted networking configuration, which is fine if you have expertise and need the power, but broadly speaking most don't need that power but they do need simplicity.
They might have decided their equipment works best with small broadcast domains and just focus on layer 3 technologies, but a shop may have been doing just fine with their oversized broadcast domain because their network vendor made the most of that sort of topology rather than skipping it because it's a bad idea.
Well, I was assuming the parent was joking, that it could be software all the way down, which isn't obviously possible.
In terms of software defined switches, generally speaking they consider any switch that can be ONIE to be 'SDN-friendly', and some others.Sure, there are switching chips doing the actual moving of the data (there pretty much has to be), but their primitive capabilities are exposed to software for more in depth wrangling.
In practice though the complexity of SDN switching is well beyond the point of diminishing returns for almost everywhere to bother with.
I'm with you there. Some things the camera wouldn't be able to capture that was being bragged about (different planes of focus, though this is something I personally haven't been bothered by in my VR experience).
Either way, being *way* later to market and seemingly no better than the 'lame' AR already there does not seem like it was worth the investment..
Two disappointments from the video: latency (the rock reacts to the hand well after the hand was there) and the translucency (everything is 'ghosty', a persistent problem for AR to present 'real' seeming things).
However, it did seem to do a serviceable job with fixed hard surfaces (floor and wall) and would probably be good enough to do the 'whale out of the floor' animation.
Of course, it never really did, the rabbit always died, pregnant or not, when they were relevant to the testing.