It's all down to personal opinion, as long as it does what you need
quickly and effectively then it's fine. I've yet to see the dark side
in cannonical so I honestly can't say much about their ethics.
Either way, I <3 Linux and so should Valve.
On 15 June 2010 00:19, Katrina Payne <fullmetalhar...@nimhlabs.com> wrote:
> Well a few points:
>
> The commands in the Linux Commandline... and well those on any UNIX or UNIX
> Workalike have not really changed since the 1970s. You could pick up a book on
> BASH or TCSH from the 1970s, and still have most of what you should do.
>
> This kind of has allowed for tools to be put around these base functions, such
> as autocomplete, history and well--quite a few other really handy tools, to be
> added into the Linux CLI, to make its functionality go above and beyond
> anything cmd.exe is capable of.
>
> I still have yet to look into Microsoft's PowerShell though.
>
> This is why most Linux users use the CLI. It has developed into an experience
> that is completely unlike the root canal that is cmd.exe. You can actually go
> in, and get some functionality from it. A lot of functionality too. It also
> gives the feeling that the user has more direct control--without that Pesky
> GUI in the way (though, technically, this just has a bunch of other items
> typically in the way, such as init.d, bash, various bash extensions--maybe
> screen... you are just trading one thing in the way, that is, a GUI, for
> another thing, that is a CLI).
>
> Now, that said--there are plenty of Desktop Environments ('DE') that Linux can
> make use of, that pretty much make requirement of CLI use unnecessary. That
> is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user
> nearly never has to do anything on the CLI. Unless something has gone horribly
> wrong. In which case, he should be able to get the local Linux Admin to fix
> it.
>
> As that technically is what he'd do if something went horribly wrong on
> Windows. He'd get his local Windows Expert to fix it.
>
> The "required" use of the CLI rather than GUI to properly use Linux, is much
> like how using Vi is "required" rather than EMACS for the proper use of Linux.
>
> Also, I use Fedora, and typically find it a LOT easier to work with than
> Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the
> people upstream. The same cannot be said about Canonical, the owners of
> Ubuntu. Where, from what I have seen on their policies by past actions...
> their MAIN desire is to be asshats to the upstream.
>
> I have a long winded rant on why I do not like Ubuntu... I mostly just state
> that nobody uses Ubuntu Linux. Typically most people go over to another Linux
> Distro afterwards, generally agreeing that no matter what Linux Distro they go
> to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack,
> Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or
> they return to Windows--only using Ubuntu as a rescue disk setup.
>
> Right, now then. Back to your regular discussion
>
> ~Katrina
>
> On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote:
>> People like the command line because it's very fast to do what you
>> want if you know what you are doing. So far ubuntu seems to be the
>> most user friendly linux distro and what a majority of linux gamers
>> might use.
>>
>> Personally I'd just use arch-linux and optimize my system...a lot. As
>> long as nVidia release decent linux drivers it's all good.
>>
>> On 13 June 2010 14:01, Adam Buckland <adamjbuckl...@gmail.com> wrote:
>> > A couple of things:
>> >
>> > Elan Ruskin gave a good talk on porting to consoles at GDC08. The
>> > slides are on Valve's website. There's something in there that may
>> > help you here:
>> >
>> > #ifdef __GNUC__
>> > #define MAXSI_THREADED_VARIABLE __thread
>> > #else
>> > #define MAXSI_THREADED_VARIABLE __declspec( thread )
>> > #endif
>> >
>> > You may wish to use another define for windows rather than an else
>> > statement in case you wish to port it somewhere else in the future.
>> >
>> > Also I agree, the Mac and Linux ports are incredibly similar. In fact,
>> > on the Mac port a shell script is executed first to determine whether
>> > it's running on OS X or Linux.
>> >
>> > Finally Linux could be a great consumer platform. Before it can become
>> > this, it needs to learn that not everyone is a power user, and make
>> > things simple. Learn from the Mac app bundles, and remove reliance on
>> > the command line (for example the output is shown on the update
>> > software). It scares normal users. That, and a lot of power users
>> > (like myself), don't want to have to rely on the command line for
>> > everything.
>> >
>> > On 13 June 2010 13:28, Jonas 'Sortie' Termansen <hlcod...@maxsi.dk> wrote:
>> >> I'd like to share a few experiences about porting code and writing
>> >> portable code. Scroll down, if you just want my thoughts on how portable
>> >> the Source Engine is.
>> >>
>> >> Recently I've been porting my in-development digital distribution
>> >> platform to GNU/Linux for the fun of it. Naturally, most of my code
>> >> didn't work right out of the box. But it is worth that several
>> >> subsystems actually worked at the first attempt, or with an edit or two.
>> >> For instance, my string system and parser classes/functions compiled
>> >> right away.
>> >>
>> >> However, stuff like accessing the filesystem, multithreading, user
>> >> interfaces, networking, and so on didn't work because it relied on the
>> >> Windows API. The interesting part here is that POSIX does things
>> >> differently; but almost in the same manner as Windows. That means for
>> >> each Windows API call you use, there is often one or more POSIX calls
>> >> that does the same thing (if you add a little abstraction, that is).
>> >>
>> >> Now, some of you heavily suggested the use of #ifdefs all around the
>> >> code. You should not use #ifdefs each time you rely on platform specific
>> >> behavior, but only in shared function calls or in headers. For instance,
>> >> if you have to open a file. On Windows you can call the CreateFile
>> >> function, while POSIX supports the open function. That means for each
>> >> file opening, you need to write something like.
>> >>
>> >> #ifdef linux
>> >> int FileHandle = open(Path, Flags);
>> >> #elif defined(WIN32)
>> >> HANDLE FileName = CreateFile(...)
>> >> #endif
>> >>
>> >> Naturally, this isn't very pretty. And if this was used all over the
>> >> Source Engine you would spend a lot of time writing #ifdefs and checking
>> >> platform specific documentation. However, I am not saying #ifdefs are a
>> >> bad idea. But instead of using them all over your code, you should move
>> >> them to a shared class or function that simply implements all this once.
>> >> In my code, I declared an abstract baseclass called MaxsiFileSystem that
>> >> implements all the common functions to access the local filesystem. So
>> >> now when I wish to open a file for reading, I would call:
>> >>
>> >> MaxsiHandle FileHandle = FileSystem()->OpenFile(Path, MAXSI_FILE_READ |
>> >> MAXSI_FILE_SEQUENTIAL);
>> >>
>> >> This additional layer of abstraction makes it very easy to add support
>> >> for new platforms as you just have to define a new child of the abstract
>> >> baseclass. I have also added such a layer for my Window System. This
>> >> means I call my own APIs in my actual code, and then it redirects it to
>> >> the Windows API or GTK+ depending on your platform.
>> >>
>> >> You might also have noticed I implemented a FileSystem() function, in
>> >> the same manner I have implemented a WindowSystem() function that
>> >> returns the window system in use by the current function/class. This
>> >> makes it easy to simply swap the window system on the fly. For instance,
>> >> my source mod links against my distribution platform (LGPL) and my mod
>> >> then implements some of these interfaces. It could implement the
>> >> MaxsiWindowSystem class using VGUI and then my programs could be
>> >> natively drawn ingame with mininal work.
>> >>
>> >> Other porting issues includes how the VS compiler breaks a lot of the
>> >> C99 standard. To counter this, I have simply declared a lot of macros in
>> >> my header files that replaces platform specific behavior. #defines are
>> >> very powerful for this. For example, to declare a thread-specific
>> >> variable, I would use this header define:
>> >>
>> >> #ifdef __GNUC__
>> >> #define MAXSI_THREADED_VARIABLE __thread
>> >> #else
>> >> #define MAXSI_THREADED_VARIABLE __declspec( thread )
>> >> #endif
>> >>
>> >> And then use the MAXSI_THREADED_VARIABLE macro to declare each threaded
>> >> variable. My experience is also that the GNU Compilers throw much more
>> >> errors and warnings than the Visual Studio compiler - and it is often
>> >> right to do so. Visual Studio teaches you to write bad
>> >> standards-breaking code, even if you just compile using MinGW you will
>> >> get to fix a lot of issues that makes your code rather non-portable.
>> >> (Like avoiding Microsoft-specific extensions to the C Library, in some
>> >> cases.) But Microsoft did break the standard enough that you might need
>> >> to use some of the above methods for porting, just to get your code
>> >> compiling using MinGW.
>> >>
>> >>
>> >> Now to return to the Source Engine. In my experience a lot of stuff in
>> >> the SDK code is already defined using interfaces, classes, and such.
>> >> That means the actual porting issues have been outsourced to the Engine.
>> >> This, in turn, means that the SDK code will be rather easy to port
>> >> compared to the Engine. Fortunately, as the Source Engine already is
>> >> highly modular using interfaces, it is easy to just swap a DX renderer
>> >> with OpenGL. As such, they already have the framework to make their code
>> >> work on new platforms - all they have to do is implement their
>> >> interfaces using the local system calls. If you start to do this on the
>> >> low-level interfaces and move upward, then soon your program starts
>> >> working in all its glory.
>> >>
>> >> As for a Steam Client for GNU/Linux. It exists. I lost the link, but it
>> >> seems that Valve uploads nightly builds of their Steam Client, and each
>> >> day it works just a bit better. Last I heard, the Steam Client actually
>> >> logged on and the actual UI was partially drawn. I am not sure why Valve
>> >> is so silent about this - perhaps it's just experimental, or they they
>> >> to make a big deal about it, like they did with the Mac. Seriously, when
>> >> are they gonna shut up about it? Last I saw was that they made a funny
>> >> TF2 comic about it.
>> >>
>> >>
>> >> Porting programs to Linux hasn't been very hard for me, though it is a
>> >> lot of work, if you want to do it properly. It seems that the Source
>> >> Engine is already highly portable and GNU/Linux build doesn't seem too
>> >> difficult, as it seems from the nightly builds. There is no doubt about
>> >> whether we need a client for GNU/Linux, it is just a matter of time
>> >> before they announce and release it.
>
>> > Bucky
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives, please
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
