Re: "script" command quits upon resize of terminal window (konsole)
On Sun, Mar 9, 2008 at 12:27 PM, Felix Endres <[EMAIL PROTECTED]> wrote: > > I would like to record everything I do for my thesis, including output. > But refraining from resizing the window is too uncomfortable. > What can I do? You can file a bug against script in Launchpad[1]. Have you opened a bug report yet? [1] https://launchpad.net/ubuntu/+filebug/+login -- Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Vinagre is confusing
On Feb 9, 2008 12:02 PM, Mackenzie Morgan <[EMAIL PROTECTED]> wrote: > I'm guessing because VNC is kind of standard. He's indicating that the name is confusing. The standard for connecting to Windows systems is Terminal Server Client. Of course, the expansion of VNC (Virtual Network Computing) is even more confusing. I'm not sure what the solution is other than to perhaps indicate in parenthesis what each is for. Remote Desktop Viewer (VNC Client) Terminal Server Client (Microsoft Windows RDC) -- Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: USB drives and unmounting
On Jan 29, 2008 12:53 PM, Vadim Peretokin <[EMAIL PROTECTED]> wrote: > Nobody know? > > This is still pretty annoying not knowing when can you really take out the > USB, forcing you to wait "just to be safe". When you unmount the drive, it's safe to remove when the icon disappears from your desktop. If you are using the command line, it's safe to remove when it no longer appears to be mounted. -- Chris "In 39 years, I have never written these words in a movie review, but here they are: You owe it to yourself to see this film. If you do not, and you have grandchildren, you should explain to them why you decided not to." -- Roger Ebert, reviewing Al Gore's documentary, An Inconvenient Truth -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Appropriateness of posts to this list (Was Re: evince crash)
On Dec 2, 2007 3:10 PM, (``-_-´´) -- Fernando <[EMAIL PROTECTED]> wrote: > I agree that : > On Tuesday 23 October 2007 05:25:56 Matthew Paul Thomas wrote: > > This causes people to make useless comments of the form "This bug has X > > votes, why is it only Medium importance!", which causes more e-mail > > notifications and slows down the developers further. > > but still this is a Comunity project, or is it not? > If what users and comunity desire is not the important for the "project", > then what is? I think allowing the developers of the distribution, those who have a real stake in the success of the software in its entirety, to decide where to focus their efforts is superior to allowing the mob to decide what's important. I also think that using straw-man arguments to make your point is a mistake. -- Chris "Always do right. This will gratify some people and astonish the rest." -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Bug #157099] Automatic installation of DVD CSS support
On Nov 26, 2007 1:10 PM, Denis Washington <[EMAIL PROTECTED]> wrote: > Hi, > > I would like to draw attention to a proposal that I think is very > important for Ubuntu as a desktop deistribution: the possibility of > automatically enabling CSS decryption support for DVDs, like it is already > possible to > retrieve support for certain audio/video endcodings automatically. See: > > https://bugs.launchpad.net/ubuntu/+source/gstreamer/+bug/157099 > > It would be great if you commented on this. Please read the comments in the bug you linked to for explanation as to why this will not happen. -- Chris "Always do right. This will gratify some people and astonish the rest." -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checking /usr/local/ before upgrading
On 10/30/07, Jan Claeys <[EMAIL PROTECTED]> wrote: > Op dinsdag 30-10-2007 om 10:46 uur [tijdzone +0100], schreef Vincenzo > Ciancia: > > I expected anything out of this thread, but people defending the idea > > that keeping /usr/local/lib in the library path during system upgrades > > is a good idea. I can accept to have problems *after* the upgrade, but > > not to be left with an unusable system just because I had stuff in > > /usr/local and that's my fault. > > Everyone can answer on this list with what is their personal opinion, so > why are you surprised to to hear any particular opinion? :) >From the FHS document: "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."[1] If you rename it, move it, or otherwise get rid of it, you're "overwriting" the contents of /usr/local. You are "removing" it from integration with the system. The onus is on the system administrator to test their software to ensure that it works with a new operating system release. If the system administrator doesn't do that, it's not the fault of the operating system that the software doesn't work. If it's unknown if the software will work or the system administrator wants to preserve /usr/local while not having it visible during the upgrade, then they need to take care of that themselves before performing the upgrade. Are you suggesting the installer present a message saying something like, "The contents of /usr/local may or may not be compatible with this release. Would you like to rename /usr/local to /usr/local.save now and verify compatibility later? [Yes] [No]"? While I don't have an issue with that, will doing so break compatibility with the FHS? [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE23 -- Chris "To announce that there must be no criticism of the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public," said President Theodore Roosevelt. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checking /usr/local/ before upgrading
On 10/30/07, Vincenzo Ciancia <[EMAIL PROTECTED]> wrote: > Christofer C. Bell ha scritto: > > > There's nothing wrong going on here. This was a simple case of user > > error. The user installed software (albeit under a different release) > > that was not compatible with the current release. The system was > > configured to use software installed in /usr/local prior to being > > upgraded, and continued to do so after being upgraded. That this > > software was incompatible with the newly installed operating system is > > not the fault of the operating system. > > Not to be picky, but the libz that I had in my system actuall was > compatible with the release I was using, hence I did never notice a > problem. Is the _new_ release which is not compatible, where is my error > then? If I can't know in advance what libraries will break the new > system, I have to remove the whole /usr/local before upgrading, this can > be done harmlessly by the system upgrader. I understand that. I'm not saying you're "at fault" in terms of you being negligent, not in the least. I'm saying that the "issue" here isn't caused by the the distribution. If you want to blame some abstract document, blame the FSSTD for allowing Unix systems to even have a /usr/local. Ubuntu is obeying that standard here. It's not messing with anything in /usr/local. That the software installed there was not compatible with Gutsy is not the fault of Ubuntu. Basically what this boils down to is that yes, the onus is on the system operator (user, administrator) to determine, either in advance or through testing, that software installed by hand is or is not compatible with a new release of the operating system. If you can fault Ubuntu with anything here, it's that compliance with the FSSTD forces Ubuntu to assume that software in /usr/local is compatible with itself. Because software in this location is, by definition, installed by hand, compatibility testing will likewise have to be "by hand." > If the user has to foresee any problem with non-distribution packages or > programs, why does ubuntu modify /etc/apt/sources.list? Shouldn't it > apply the same principle, and just leave it untouched? If third party > repositories break the system upgrade, it's just an user error. Yes, if third party repositories break the system, it is user error. I would in this case suggest using the /etc/apt/sources.list.d directory for including third party archives. It is a known caveat that including third party repositories with your sources can cause issues with your operating system. This is not the fault of Ubuntu and the system should not be expected to protect you from yourself in this case. -- Chris "To announce that there must be no criticism of the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public," said President Theodore Roosevelt. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Checking /usr/local/ before upgrading
On 10/29/07, Pär Andersson <[EMAIL PROTECTED]> wrote: > > That is really wrong, placing something stupid under for > example /usr/local/bin should really not break upgrades or any other system > software. Please read chapter "9.1.2 Site-specific programs" of the Debian > Policy Manual, Fergal provided a link and a quote of the most relevant part > in his e-mail. There's nothing wrong going on here. This was a simple case of user error. The user installed software (albeit under a different release) that was not compatible with the current release. The system was configured to use software installed in /usr/local prior to being upgraded, and continued to do so after being upgraded. That this software was incompatible with the newly installed operating system is not the fault of the operating system. ie; There is nothing to be learned by over analyzing this issue other than a valuable life lesson on the part of the system administrator. -- Chris -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Single CD for Server & Desktop?
I'm curious why there are 2 CDs, one for Server and one for Desktop. Is it not possible to have a check box at installation time that says: * I would like to install an Ubuntu Desktop [ ] * I would like to install an Ubuntu Server [ ] Just idly curious. ;-) -- Chris "To announce that there must be no criticism of the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public," said President Theodore Roosevelt. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Accepted mdadm 2.6.2-1ubuntu1 (source)
On 7/13/07, Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > I'm inclined to agree. Bringing up a degraded array, and allowing the admin > to recover it in a normal administration scenario, should always be better > than failing the boot. Allowing the array to come up degraded is the default behavior in Veritas. The goal is availability. Degraded or not, the data is available. It's available during the drive failure, and should be available after a reboot. > If the concern is over data consistency, is it not possible to bring it up > read-only? I'm not convinced that any action other than "bring up the array read-write in degraded mode" is necessary. This ensures data and application availability and allows the administrator to take action while the system is up and running (one of the key points to using RAID, along with ensuring data is not lost to drive failure). -- Chris memes don't exist -- tell your friends -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
