Which of course you can do that, but then you can't have the database LV and the log LV on different physical disks any more, which is what was asked.
Can you post an example how you would concatenate two existing LVs, with existing file systems on them, mounted and being modified at the time. into a "new virtual block device" without even un-mounting them, and then make a consistent snapshot of them?
Put your money in the Bank of Aldreaan, they said. Safest bank in the universe, they said. They'd have to to blow up the entire planet to get in there, they said.
In a German comedy show (back in the 70s or early 80s) they presented an "ultra-wide-cimema-maxi-super-scope or something" format, where they presented a 100m dash run "in it's entirety" on screen from start to finish without panning or zooming. It was like about a 160:9 ratio. They apologized for the "slight black bars at the bottom and top" when presented on the 4:3 TV sets. Which was basically completely black with 2-3 scan lines lit in the middle.
It might be difficult because if there is a bug (or a malicious hack) in the installer, then the installer could delete all other databases on that server once it has obtained the sa password of that server.
The question basically boils down to "How much do I trust an installer I have no clue about what it actually does to mess with my systems."
Exactly. Being both a developer and an admin having "installers" is often worse than not having them. I much prefer the "copy the software files somewhere, set environment variables A, B and C, and fill out configuration files X, Y and Z"
An administrator in an enterprise environment should know better how to to those things in HIS environment than a person that has to write an installer that has to fit ALL environments. I can't count the times I had to snapshot a system, run an installer, and then compare the systems to find out what the installer was doing so that I can figure out what needs to be done in my "real" environment, because the installer didn't work in my real environment. A good list about what needs to be done is often more helpful than an automated installer.
A ping point there being "Shareholders". I myself (42 years at the moment) would NEVER (again) work for a publicly traded company. Small, privately owned, outfits are the place for me. Where Priority one is the customer, priority two are the workers, and the owners profit is priority three. (Funny enough, it seems the owners profit gets better when it's priority three than when it's priority two)
Uh-Oh. Time to look into that, and how to avoid that. But as far as I can see the change so far only affects the default choice on the new install media, so I hope there is still at least a 1-2 years period in which we see if the whole thing straightens itself out or if it goes up in flames. Especially since it seems to be completely contrary to the "KISS" principle for which I choose ARCH. (For home use and a few dozen service boxes at work)
For example one points from the systemd Wiki page:
Service startup is determined by a configuration file in a declarative language, rather than a shell script for each service.
Both for my home boxes and for the ones at work it is "crucial" that I am able to hack together a quick and dirty service with just a few shell scripts. With the full flexibility to use different shells. To basically be able to have the entire system / service configuration in one little rc.conf was also part of the reason I choose Arch over other Distros.
Not with video work. With upstream being a lot slower than downstream, it's not viable to wait a few hours before your video is uploaded into the cloud.
I work for a company with about 20 branches, and while all or office/mail stuff runs in (our own) cloud desktops, even things like "upload a couple of pictures to mail to a supplier" bandwidth into the cloud become problematic. That's why we still have to keep at least one machine "local" to do such stuff in every branch.
Well, beside the "download limit/no download limit" and the "content provider pays" there would always be the third option "receiver pays for his data volume"
That could even be a two-tier system. "expensive" protocols that run "I want that data now!" stuff and cheap protocols that run "Transmit that data off-peak sometime when there is free capacity" stuff.
Commentators (including myself) have been predicting the end of the internet (as we know it) for almost two decades now -- but I (and all the others) have been proven wrong.
Well. When you think about it, the Internet from two decades ago IS gone. Otherwise you are right.
Back 20 years ago here in Germany I had to pay per-minute long-distance rates do dial into CompuServe. 9.6 kb, connected 1-2 hours a day costed about 4-5 times what I pay today for a 24-hour always on 16Mb down 2Mb up link. What I would really hate would be to have "caps", though. I would have no problems paying per byte on the other hand.
You seem to be under the impression that "stealth" means "undetectable".
That's not true. Stealth in the past, in the present, and in the future in a military sense just means being so hard to detect that your opponent hat to spend considerable more resources to detect you than you need to detect him.
Yep. So it's basically "work for nothing for a time to fill $mega-corps coffers WHILE you are at school" in China with this scheme versus "work for nothing for a time to fill $mega-corps coffers AFTER you left school" to pay back your student loans in the US. Pure Capitalism at work in both cases.
releasing NEW software is FUN, while spending years doing bug fixes, regression testing, and QC? Is about as fun as getting a root canal at the DMV
That's why I think that the whole "let's bring the Linux desktop to the masses" approach is flawed.
FOSS is at it's best when there is a huge overlap between the people who use the software and the people who write the software. Because THEN fixing bugs that impede "getting the work done" has a higher priority than cranking out new features. There are a lot of examples of software that hasn't really "changed" feature-wise in years, even decades. (bash, vim, lynx, slrn) and so on. Sooner or later I hope some of the GUI alternatives will reach the same level of maturity, so that they just "work as intended" and the user interface doesn't need to be changed all the time. That could be a huge market. A lot of corporate environments begin to get fed up with having to re-train users all the time, they stick with old software mainly because it isn't practical to switch work-flows around all the because someone decided to try a new interface design he thought to be cooler.
Having a line of FOSS alternatives that focus on not changing interfaces all the time, but to keep them stable and consistant long-term could be a way to get more FOSS adoption on the desktop side in corporations.
These carriers will not track the location of your phone.
Then nobody will ever be able to call you on that phone. They *must* track where the phone is, so that they can connect the call to the right cell tower.
In the early ages of mobile (car) phones ( pre - 1990 completely analogue systems) you weren't tracked, but then the caller had to call the "area code" of the radio area he believed you were in.
Actually, I *have* seen software that doesn't have that problem. Both in the open source and closed source world.
It's all those little things that someone wrote (or had someone write) who had a problem and solved it with that piece of software. What they all seem to have in common, is that the developer basically does *as little work as possible*, those only implements things that *solve the problem better* not things that primarily meant to *attract new users*. Which most often pisses off existing users. ( Kinda like the "Why the hell do I have to wait X minutes in line to reach a company as an existing users, when at the same time they have call centers full of people out there cold-calling to attract new user." problem.)
Slashdot Mirror
Which of course you can do that, but then you can't have the database LV and the log LV on different physical disks any more, which is what was asked.
Can you post an example how you would concatenate two existing LVs, with existing file systems on them, mounted and being modified at the time. into a "new virtual block device" without even un-mounting them, and then make a consistent snapshot of them?
Don't remind me about Alderaan.
Put your money in the Bank of Aldreaan, they said. Safest bank in the universe, they said. They'd have to to blow up the entire planet to get in there, they said.
Of course 90% of that computer power is used up thinking up snarky remarks.
In a German comedy show (back in the 70s or early 80s) they presented an "ultra-wide-cimema-maxi-super-scope or something" format, where they presented a 100m dash run "in it's entirety" on screen from start to finish without panning or zooming. It was like about a 160:9 ratio. They apologized for the "slight black bars at the bottom and top" when presented on the 4:3 TV sets. Which was basically completely black with 2-3 scan lines lit in the middle.
Film at 11.
Don't bother, it's not that good. I already watched my unauthorized copy three weeks ago.
Not when you are eating the new iChocolate!
With a built-in non-swappable battery that heats it to 120 C ( 248 F ) while in your mouth so that it melts?
Now show farting and wrestling jokes on the other hand .......
It might be difficult because if there is a bug (or a malicious hack) in the installer, then the installer could delete all other databases on that server once it has obtained the sa password of that server.
The question basically boils down to "How much do I trust an installer I have no clue about what it actually does to mess with my systems."
Exactly. Being both a developer and an admin having "installers" is often worse than not having them. I much prefer the "copy the software files somewhere, set environment variables A, B and C, and fill out configuration files X, Y and Z"
An administrator in an enterprise environment should know better how to to those things in HIS environment than a person that has to write an installer that has to fit ALL environments. I can't count the times I had to snapshot a system, run an installer, and then compare the systems to find out what the installer was doing so that I can figure out what needs to be done in my "real" environment, because the installer didn't work in my real environment. A good list about what needs to be done is often more helpful than an automated installer.
A ping point there being "Shareholders". I myself (42 years at the moment) would NEVER (again) work for a publicly traded company. Small, privately owned, outfits are the place for me. Where Priority one is the customer, priority two are the workers, and the owners profit is priority three. (Funny enough, it seems the owners profit gets better when it's priority three than when it's priority two)
Uh-Oh. Time to look into that, and how to avoid that. But as far as I can see the change so far only affects the default choice on the new install media, so I hope there is still at least a 1-2 years period in which we see if the whole thing straightens itself out or if it goes up in flames. Especially since it seems to be completely contrary to the "KISS" principle for which I choose ARCH. (For home use and a few dozen service boxes at work)
For example one points from the systemd Wiki page:
Service startup is determined by a configuration file in a declarative language, rather than a shell script for each service.
Both for my home boxes and for the ones at work it is "crucial" that I am able to hack together a quick and dirty service with just a few shell scripts. With the full flexibility to use different shells. To basically be able to have the entire system / service configuration in one little rc.conf was also part of the reason I choose Arch over other Distros.
I heard rumours they also tried cheaper Hollywood-style encryption, but they had to many casualties because the drone wasn't operational fast enough.
They had to watch too many FBI warnings before they could start it up.
Not with video work. With upstream being a lot slower than downstream, it's not viable to wait a few hours before your video is uploaded into the cloud.
I work for a company with about 20 branches, and while all or office/mail stuff runs in (our own) cloud desktops, even things like "upload a couple of pictures to mail to a supplier" bandwidth into the cloud become problematic. That's why we still have to keep at least one machine "local" to do such stuff in every branch.
But the DO have both after a year or so...
Well, beside the "download limit/no download limit" and the "content provider pays" there would always be the third option "receiver pays for his data volume"
That could even be a two-tier system. "expensive" protocols that run "I want that data now!" stuff and cheap protocols that run "Transmit that data off-peak sometime when there is free capacity" stuff.
Commentators (including myself) have been predicting the end of the internet (as we know it) for almost two decades now -- but I (and all the others) have been proven wrong.
Well. When you think about it, the Internet from two decades ago IS gone. Otherwise you are right.
Back 20 years ago here in Germany I had to pay per-minute long-distance rates do dial into CompuServe. 9.6 kb, connected 1-2 hours a day costed about 4-5 times what I pay today for a 24-hour always on 16Mb down 2Mb up link. What I would really hate would be to have "caps", though. I would have no problems paying per byte on the other hand.
Sorry, I'm more of a Ceefax person.
You seem to be under the impression that "stealth" means "undetectable".
That's not true. Stealth in the past, in the present, and in the future in a military sense just means being so hard to detect that your opponent hat to spend considerable more resources to detect you than you need to detect him.
Yep. So it's basically "work for nothing for a time to fill $mega-corps coffers WHILE you are at school" in China with this scheme versus "work for nothing for a time to fill $mega-corps coffers AFTER you left school" to pay back your student loans in the US. Pure Capitalism at work in both cases.
Perhaps there will be textbooks in 2100 that will even attribute the quote "Steve Jobs is dead" to Nietzsche then?
releasing NEW software is FUN, while spending years doing bug fixes, regression testing, and QC? Is about as fun as getting a root canal at the DMV
That's why I think that the whole "let's bring the Linux desktop to the masses" approach is flawed.
FOSS is at it's best when there is a huge overlap between the people who use the software and the people who write the software. Because THEN fixing bugs that impede "getting the work done" has a higher priority than cranking out new features. There are a lot of examples of software that hasn't really "changed" feature-wise in years, even decades. (bash, vim, lynx, slrn) and so on. Sooner or later I hope some of the GUI alternatives will reach the same level of maturity, so that they just "work as intended" and the user interface doesn't need to be changed all the time. That could be a huge market. A lot of corporate environments begin to get fed up with having to re-train users all the time, they stick with old software mainly because it isn't practical to switch work-flows around all the because someone decided to try a new interface design he thought to be cooler.
Having a line of FOSS alternatives that focus on not changing interfaces all the time, but to keep them stable and consistant long-term could be a way to get more FOSS adoption on the desktop side in corporations.
These carriers will not track the location of your phone.
Then nobody will ever be able to call you on that phone. They *must* track where the phone is, so that they can connect the call to the right cell tower.
In the early ages of mobile (car) phones ( pre - 1990 completely analogue systems) you weren't tracked, but then the caller had to call the "area code" of the radio area he believed you were in.
Yeah. Just like you could throw away all those old Caterpillar Excavators and buy everyone a Ferrari 612 Scaglietti to do that kind of work.
Actually, I *have* seen software that doesn't have that problem. Both in the open source and closed source world.
It's all those little things that someone wrote (or had someone write) who had a problem and solved it with that piece of software. What they all seem to have in common, is that the developer basically does *as little work as possible*, those only implements things that *solve the problem better* not things that primarily meant to *attract new users*. Which most often pisses off existing users. ( Kinda like the "Why the hell do I have to wait X minutes in line to reach a company as an existing users, when at the same time they have call centers full of people out there cold-calling to attract new user." problem.)
Well, if ideas not important a all, only the actual product made, then Apple shouldn't sue Samsung in the first place.