Re: [SLUG] C Gurus
O Plameras [EMAIL PROTECTED] wrote: I don't find C difficult at all. Says the guy who has already demonstrated his lack of knowledge on strlen() and how strings are represented. C has one of the least number of vocabularies to learn and master. That makes the language small, not simple. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C Gurus
Benno [EMAIL PROTECTED] wrote: Anyway, you can write good stuff in C, but really, unless computation speed is the issue [ ... ] ... and even when it is, avoid C. The compiler/VM/runtime for higher level languages is usually smarter than you are. You'll have to write the high level code first to find out which bits need optimisation anyway. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] C Gurus
O Plameras [EMAIL PROTECTED] wrote: The reality of it all is anyone can learn C in one day and master it in one week. By this I mean, after one week anyone will be able to read anyone's C code provided it is written correctly. You can't just make stuff up and pretend it's true! That's not how the world works. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Why not C
Crossfire [EMAIL PROTECTED] wrote: The reason why we see C being used so much is that we lack a statically typed high level language that doesn't completely suck ass. I like Java. It's quite popular. For some time now I've been tempted to learn Ada95 for this purpose. Shame its so unpopular. Java is also quite unpopular. :) -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Your top-ten linux desktop apps
O Plameras [EMAIL PROTECTED] wrote: And, also, in that case I should also include sizeof(unsigned) which in C programming is usually the same as sizeof(int). But we learned again that we must satisfy ourselves first hand. if (sizeof(unsigned) != sizeof(int)) printf(Buggy compiler!\n); unsigned really means unsigned int which is always exactly the same size as int (obviously). -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Your top-ten linux desktop apps
O Plameras [EMAIL PROTECTED] wrote:
In doing so I have a dramatic change in the way my program now behaves.
No. A for loop is just a different way of expressing a while loop;
they're different syntax but identical in behaviour. Watch:
for (initialise; guard; increment) { body }
initialise; while (guard) { body; increment; }
Using a for loop or while loop, you've still explicity stated the
initial state (start of the array), the guard condition (not at the end
of the array yet) and the increment (next position in the array).
In the modified program the size of array may be modified at will and
there is no need to remembering and change the loop. We may format
our array anywhere in the application and no need to change the loop.
Only works for static sized arrays, as has been demonstrated, and leads
to insidious hard to detect bugs when you change to dynamic arrays
because they're just pointers.
This is where the power of C-pointer lies. If I am prepared and able,
as a programmer, to put good and compact pointer-arithmetic into my
programs I'd get better and concise C-programs. It is in the ability
of the C-programmer. He has a fine-grained control as to what should
happen.
Humans make mistakes. Minimising the impact of the mistakes is a winning
strategy. Ignoring the fact that people make mistakes is a losing
strategy. Use C when you must, something smarter when you can.
Erik said:
By contrast, the O'caml mapi function automatically figures out
the start and end conditions from what it knows about the array.
This is what the modified C-program does with the concised while loop.
No it doesn't. You explicity told it the initial state and guard
condition, and also the increment operation. Any language with a foreach
construct will actually figure those out itself. C will not.
--
Sam Eddie Couter | mailto:[EMAIL PROTECTED]
Debian Developer| mailto:[EMAIL PROTECTED]
| jabber:[EMAIL PROTECTED]
OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
signature.asc
Description: Digital signature
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Your top-ten linux desktop apps
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 3) cvs That's ... if you have more than 1 person working on the code. ... or even if you're working alone. As for programming languages I recommand: C/C++ (gcc/g++) perl shell (script) Java Python -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Aptitude command to TOTALLY remove KDE
telford [EMAIL PROTECTED] wrote: If you do not want to go the whole hog and run a fully isolated virtual machine then you MIGHT be able to recover SOME of the time but think about a situation where you have swap-to-disk implemented as a user space task and it crashes. Can you recover the situation? All memory on the entire system is now in an untrustworthy state so you must find a way of cleanly restarting every task -- most people call this a reboot. The point of a microkernel is that for the swap to become corrupted, the swap service must be buggy. It doesn't matter to the swap system how buggy the graphics or network drivers are, for example. Different tasks can even be using different virtual memory systems, so if one crashes then processes using the others are completely unaffected. And because microkernel designs have been tried (e.g. MS-Windows NT) and so far they have proven both slower and less stable. NT was never released as a microkernel, although that was the original plan. It has only ever pretended. NT's instability is mostly due to shoddy graphics and other drivers being loaded in kernel memory for performance reasons. In other words, the instability is due to *failing* to really be a microkernel. QNX was the first microkernel to demonstrate decent performance, and that came at the cost of flexibility and performance. More recent research has lead to more portable and flexible microkernels with high performace such as L4. When Linux first came into existence, microkernels were still just a neat idea with a few big problems and were a long way from being proven. The high cost of context switches and switching supervisor mode (ring zero) on and off on x86 makes things difficult for any microkernel. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Aptitude command to TOTALLY remove KDE
Sam Couter wrote: The Hurd is just a kernel (well, a microkernel and a bunch of servers that offer services normally provided by more traditional kernels). GNOME runs on the Hurd and it's about the same as GNOME on Linux or FreeBSD or any one of a bunch of free operating systems. I don't know if KDE runs on the Hurd yet, but when it does, it'll be just like running KDE on Linux or FreeBSD or any one of a bunch of free operating systems. QuantumG [EMAIL PROTECTED] wrote: See, this is flat out wrong. No, what I said is correct. The kernel is largely irrelevant to the end-user experience. We've know since BeOS that a microkernel makes for a better desktop operating system. Who's we? I'm no kernel expert, so what I say here is probably worth exactly what you paid for it, but... While I happen to agree with you that a microkernel seems like the best (most secure, stable, flexible and extensible) possible architecture for a system to have (barring deadbrained hardware architectures like x86), whether you're on a microkernel or monolithic system makes very little difference to the end-user experience. GNOME and KDE still look and behave like GNOME and KDE whether you're on Linux, one of the BSDs or the Hurd. That is not to say that we should just throw Linux away. In fact, I advocate the opposite. We need to refocus work on the Linux kernel and step up the incremental migration of services out of the kernel. Some crazy loon whacked the Linux kernel and ORBit (a C library that implements the CORBA specs) together a few years ago. The extrapolation of such trends leads to drivers in user space on a physically seperate machine, anywhere on the planet, with any hardware architecture, and implemented in any language that has CORBA support. Now that is something I find interesting, if not immediately useful. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Aptitude command to TOTALLY remove KDE
Terry Collins [EMAIL PROTECTED] wrote: wanders off muttering If this keeps up, The Hurd is going to start looking really attractive ... The Hurd is just a kernel (well, a microkernel and a bunch of servers that offer services normally provided by more traditional kernels). GNOME runs on the Hurd and it's about the same as GNOME on Linux or FreeBSD or any one of a bunch of free operating systems. I don't know if KDE runs on the Hurd yet, but when it does, it'll be just like running KDE on Linux or FreeBSD or any one of a bunch of free operating systems. You bitch about Linux but what you speak of is only loosely related to Linux. Expecting the Hurd to solve *any* of the problems you've described so far... well... it won't. It'll be even worse due to lower mindshare, completely different system design, etc. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] bulk mail script
Alexander Else [EMAIL PROTECTED] wrote: A task has been allocated to me to send out a mail (possibly with a word/pdf attachment) to a few hundred email addresses in an hour and a half. As i don't have a lot of time to do my homework on this one, i hope someone can point me to one or two options for a script that will do this for me. If you're sending to people who do want what you're sending, use mpack: mpack -s Here's some SPAM -d /file/with/text/message -c application/pdf /path/to/pdf/attachment [EMAIL PROTECTED] If you are spamming people who don't want what you're sending, a red hot poker in the eyeball would be too kind. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Technical Support Ticket system
Rev Simon Rumble [EMAIL PROTECTED] wrote: The Debian package is pretty trivial to get running, actually. It doesn't play well with Apache2 at the moment. The mod_perl module for Apache2 changed API and RT hasn't caught up with it yet. Without the persistence features the CGI scripts are SLOW. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Linux Ethernet Bridging - Is there a legitimate use?
Lindsay Holmwood [EMAIL PROTECTED] wrote: Out of interest, why did you do that? So ethernet packets on the wired (physically secured) network aren't broadcast over the wireless (completely unsecured) network. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Xen and the art of disk allocation
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My plan is: /dev/hdb1 gentoo, xen kernel install, mbr etc /dev/hdb2 debian install bootable from xen or standard mbr /dev/hdb3 something else... [ ... ] There are other ways of doing this. I think I could be using weird file systems to pretend they are partions for example. Does anyone have any thoughts? LVM is a very useful and flexible way to partition disks. LVM volumes can be resized, moved, activated and deactivated on the fly. If you use ext2 you don't even need to unmount it to enlarge it. Some filesystems can't be shrunk but can be enlarged. To use LVM effectively, you probably want to make the drive one big partition (plus maybe a small /boot partition depending on how you boot the machine), make that partition a physical volume, then allocate bits of it to as many logical volumes as you want. Excellent documentation in the HOWTO at: http://www.tldp.org/HOWTO/LVM-HOWTO/ Disclaimer: I haven't used xen and don't really know how well it plays with LVM, although Google has enlightened me somewhat. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Is LVM worth it?
Howard Lowndes [EMAIL PROTECTED] wrote: I've just got a FC3 box in the shop with a screwed LVM setup - when it starts to boot it gets a kernel panic. I have the FC3 rescue CD but that doesn't appear to have any LVM tools on it, neither does the Knoppix CD. The Debian Sarge installer supports LVM. The netinst CD is the best rescue CD I've found. -- Sam Eddie Couter | mailto:[EMAIL PROTECTED] Debian Developer| mailto:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] USB device mappings
Ben Buxton [EMAIL PROTECTED] wrote:
How can one go about ensuring that certain USB mass-storage devices
always get linked to the right /dev node, irregardless of the order that
they're plugged into?
Irregardless? Yay for Bushisms!
I'd like to have things where by for example, my camera always appears
ad /dev/sda, my USB key as /dev/sdb, etc. It seems that they are
allocated in the order they're attached, but this makes things rather
complicated as I have to keep hunting for which device something's
attacehd to.
Install udev.
Plug each device in and look in your syslog for a line like:
Jul 29 12:28:51 localhost kernel: Vendor: USB 2.0 Model: Flash Disk
Rev: 1.00
Create or edit /etc/udev/rules/local.rules (or some other filename in
that directory) and add a line for each device using values you found in
syslog. Example:
[ wrapped for email; put it all on one line ]
BUS=scsi, SYSFS{vendor}=USB 2.0, SYSFS{model}=Flash Disk,
NAME{all_partitions}=flash
The SYSFS bits match whatever your device reports itself as. The NAME
bit is what name you'd like the device to have in /dev.
To /etc/fstab, add lines something like:
[ note the dev name: flash1 (first and only partition), not flash ]
/dev/flash1 /mnt/flash vfat user,noauto 0 0
Insert device, mount /mnt/flash, wipe hands on pants.
--
Sam Eddie Couter | mailto:[EMAIL PROTECTED]
Debian Developer| mailto:[EMAIL PROTECTED]
| jabber:[EMAIL PROTECTED]
OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
signature.asc
Description: Digital signature
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
