yong321's questions

Our team often connect to a Windows server through remote desktop (RDP). Inside RDP, we use Putty (a terminal emulator) to connect to a Linux server. Sometimes we launch X-Win32 (an X server for Windows) in RDP and run an X application on Linux to show the GUI to Windows. If only one person does this, he can export DISPLAY=[Windows server]:0 in the Linux Putty window and run the X app. If another person does this, most likely he needs to set DISPLAY to [Windows server]:1, ... The number after the colon is the X display number. We can see it by moving mouse over the X-Win32 icon at the lower right corner of RDP. But I wonder if there's a way to detect that number from Linux.

We probably can manually set an environment variable in Putty (Connection->Data->Environment variables) before we connect to Linux and once connected, the bash shell will have the variable set. Or we can run Process Explorer on the Windows server and check the environment variable DISPLAY in process ime.exe (a process spawned by X-Win32). But these are even more complicated than telling our team members to move mouse over X-Win32 icon to get the display number. Is there an easier way or a way we can automate? If none, that's fine. Thank you!

We know x86 has become much more successful than SPARC over the past 20 years, even on the server side. This in turn translates into more budget in R&D on x86. These external factors aside, is there any inherent reason why SPARC has failed? Before we begin, it would help to read John Gustafson's answer to the question about their difference (https://www.quora.com/What-are-the-differences-between-Sparc-and-Intel-architecture). In short, there's not much difference nowadays, including RISC vs CISC. He thinks pretty much the only difference is in endianness. So, the question is, why is x86 a success but SPARC is not, from a pure technical point of view? If there isn't any, that's perfectly fine, because it's not uncommon for a technically superior technology to fail in business.

I don't think this is possible on any Linux file system. But I wish to have a feature of setting a file to be undeletable but keeping the file updatable. Note the latter requirement cannot be met with the immutable bit of chattr.

This is potentially very useful as most of us have done accidental delete at least once in our career. Keeping the file updatable is important so that applications can continue to modify data in the file.

What I have in mind is datafiles of various databases. They are fixed in size for some time or all the time depending on the database setting. They are modified in-place. I imagine it's an easy feature to add to chattr since other file attributes are already in there, although not always implemented in common file systems.

DBAs are absolutely held responsible to have good backups of the databases. But that's a different topic. Besides, datafiles could be accidentally deleted by system admins.