Xen wrote:
Not sure why all good engineers seems to be women.
Maybe it's there are so few in the field -- that of the ones that have stayed in the field for any length of time tend to do so because they really liked the field? Vs. w/ males, because there are so many in the field, the good ones don't stand out as "memorable-enough" from the crowd? I don't know about other woman, but unlike a bunch of people who entered the field in the late 1990's and early 2000's because of the "dot com" bubble and high salaries, I really am an engineer & scientist -- w/an engineering degree in Computer Science. My alma mater had 2 Computer Science degree tracks: one in the Liberal Arts school that had more emphasis in math, and the other from the Engineering school with more emphasis on systems and OS design. Though, more often than not, I don't think I'm that good as much as I'm able to make mistakes and correct them more quickly than most. More often than not, I try not to get hung up on things that don't work, and instead try to focus on fixing them...
But new cygwin-64 tools run native and run just fine from a win7-64 repair console, so maintenance that much easier now.
Do you mean you run them from your harddrive after setting up path?
If you are on a 64-bit machine, 32-bit programs don't run 'natively, but use a special 32-bit adaptation layer (or subsystem) layer that resides in the C:\windows\syswow64 (Sys-Windows-on-Windows64). If you are boot into the "recovery console", used for system rescue, programs that depend on other add-on layers/subsystems like the GUI, POSIX, and SysWoW64 can't run as those extra subsystems aren't loaded.
It's not linux, but the unix tools available on linux OR on cygwin64 -- which you can run under win7's repair console.
Buh. Cygwin or not cygwin, I never really liked that. I used GnuWin32 tools but I can't say I have ever really used cygwin, even when I had it installed. Stuff didn't work. I don't know why.
--- The gnuwin32 tools don't use or try to provide a 'Posix-compatible' layer, whereas Cygwin does try to provide such a layer. I've taken some of the linux source rpms and build the binary-rpms using 'rpm[/build]' on Cygwin -- because many of the same linux-like utils are there (bash and most the command-line utils, vim/gvim -- even some of the linux desktops have been ported.
I think I had trouble with e.g. slashes in filenames (backslashes). A think I tried to do in cygwin just wouldn't work whereas in Linux it was or would have been easy and flawless. I gave up.
--- Cygwin uses 'slashes', same as linux, the Gnuwin32 and Gnuwin64 tools try to work with the Win-backslash type paths. I've yet to see a gnuwin-version of bash there, though, but you do have bash w/cygwin. Cygwin isn't as fast as running linux native, but is comparable in the user-code and sufficient for shell scripting.
I think pipes (named pipes as well) should in some way remain or be the way of interprocess communciation as well. No matter how it should be implemented, the pipe should be the future.
Not always ideal if you are using multiple processes -- even in linux, it's not possible to do 2-way communication over a pipe -- (pair of pipes, yes, but you can't easily setup 2-way communication between processes in standard shell or bash).
I'm not sure. In principle the concept of a pipe extends beyond one-way and can be multiplexed and all that. I've never done any multi-process or IPC communication myself. Let's say my experience is limited to doing these things in Java with threads. But that's not, that's hardly something you can just create in a short time. Java is not exactly suited for scripting.
True...but even just '2-way communication' is hard in bash -- i.e. you can't easily setup a pipe to 'sort' and read the output from the same process. I think 'co-processes' are supposed to allow that, but I never got them to work reliably.
I also have no perl experience which makes it a bit hard.
If you start out simple in perl -- and use it for 1-liners, it's not that hard. Perl started out being a combination of shell+awk+sort+sed+tr -- all the common unix utils but in 1 program. Perl-V added some basic Object-Oriented support which allowed it to be more useful as a general purpose programming language, but the language has mostly stagnated since V5.6 (it's now at 5.22).
Cool how you design stuff. I like your designs, but then I already knew that kinda in advance that I would, because I / we agree on so many things. I will need to find out at some point how these things are being done. For now the only machine I use for flac -> mp3 has one core :P :P :P :P (is VPS).
Even w/1 core, you can improve on efficiencies (though more worth your money to get more cores, usually) as file-I/O isn't usually handled by the main processor but by a disk-controller that can do DMA in background while the foreground compute process does the compute stuff (wave->flac or wave->mp3).
It would have been really painful to try to do that with pipes alone, since they only buffer ~8k/pipe -- would have been alot of overhead in process switching.
Muh, you know 30x as much as I do. I feel... rather jealous really :)
These days, the amount of stuff to learn is increasing exponentially with 'old knowledge' often getting outdated.
Damn, I thought I would have been more experienced by now. Things didn't really go as intended. That's why I will start over :p :). I can't live with this jealousy all the time.
Most the stuff I've learned I've learned on my own trying to solve my own problems -- but alot of it I've learned by building and adding on features to other people's programs -- if you have an 'itch' to scratch with some open-source program, you can often compile it and make little changes to see how things work. Later on, you make bigger changes...Hardest is writing programs from scratch -- since you have to build a "virtual framework" first (that's the design part -- when you have the most freedom and most opportunity to go in a wrong direction). Even though I've had tons of experiences going the wrong way, I still increased my knowledge and learning in those areas.... Problem today, is most people want it done right the first time and take any 'side' ventures as a waste of time -- even though they usually aren't because of the additional stuff you learn.
Heh, good to know. I would have writtein it in Java or Python but then I don't even know how these thigns (well, Java) would be able to communicate with "a system".
Well, have to say writing my snapshot prog in shell, 1st, was a learning experience! ;-)
Anyway, thanks for the message.
At least 1 person liked it.... most can't wade through my verbosity. ;-)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org