Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110548 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2017-05-24 08:16 -0700 |
| Last post | 2017-06-03 11:29 +0000 |
| Articles | 20 on this page of 82 — 20 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:16 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-24 10:43 -0700
Re: C Macros Badly Defined? Ike Naar <ike@iceland.freeshell.org> - 2017-05-24 19:06 +0000
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-27 06:10 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 12:02 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-27 13:42 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-27 15:48 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-28 14:40 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:33 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:17 -0700
Re: C Macros Badly Defined? bartc <bc@freeuk.com> - 2017-05-29 16:26 +0100
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:13 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 09:57 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 19:12 +0200
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 14:55 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 15:39 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 16:03 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-30 16:50 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-30 17:12 -0700
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:30 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:36 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:08 -0700
Re: C Macros Badly Defined? scott@slp53.sl.home (Scott Lurndal) - 2017-05-31 19:16 +0000
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:35 -0700
Re: C Macros Badly Defined? Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:06 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:33 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 12:00 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:35 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-01 17:26 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 20:48 -0700
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 12:43 -0700
Re: C Macros Badly Defined? David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:50 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:36 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 11:44 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-06-03 09:19 -0700
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-03 16:22 +0000
Re: Standards in various formats Noob <root@127.0.0.1> - 2017-06-01 13:24 +0200
Re: C Macros Badly Defined? jadill33@gmail.com - 2017-05-31 13:02 -0700
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 22:06 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 12:51 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-05-31 06:21 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-05-31 17:16 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:24 +0200
Re: C Macros Badly Defined? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-31 22:18 +0200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:09 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 17:32 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 23:50 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 18:01 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:33 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-31 22:36 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 06:08 +0200
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:08 -0400
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 01:30 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 11:38 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 03:13 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 12:25 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 04:48 -0700
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 14:27 +0200
Re: C Macros Badly Defined? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-01 05:55 -0700
Re: C Macros Badly Defined? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-01 11:11 -0400
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 17:40 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 08:32 +1200
Re: C Macros Badly Defined? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 23:14 +0200
Re: C Macros Badly Defined? jameskuyper@verizon.net - 2017-06-01 14:41 -0700
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 09:48 +1200
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 00:56 +0200
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:12 +1200
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:54 +0000
Re: C Macros Badly Defined? Leon Taylor <leontaylor476@gmail.com> - 2017-06-03 05:10 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-04 14:32 +0200
Re: C Macros Badly Defined? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-01 21:44 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:51 +0000
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 21:38 +0000
Re: C Macros Badly Defined? Ian Collins <ian-news@hotmail.com> - 2017-06-02 11:10 +1200
Re: C Macros Badly Defined? gazelle@shell.xmission.com (Kenny McCormack) - 2017-06-01 23:34 +0000
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:48 +0000
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-01 08:56 -0700
Re: C Macros Badly Defined? David Brown <david.brown@hesbynett.no> - 2017-06-02 14:11 +0200
Re: C Macros Badly Defined? supercat@casperkitty.com - 2017-06-02 10:02 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:45 +0000
Re: C Macros Badly Defined? Keith Thompson <kst-u@mib.org> - 2017-05-31 09:11 -0700
Re: C Macros Badly Defined? raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:29 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 17:40 +0200 |
| Message-ID | <20170601174058.99245b1c91eb4eab2e724b8d@gmail.com> |
| In reply to | #111109 |
On Thu, 1 Jun 2017 11:11:54 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote: > You can buy computers with no OS installed, and install the one of your > choice. Even a laptop... too smart the old monkey. :o)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-02 08:32 +1200 |
| Message-ID | <epbbufFuc47U2@mid.individual.net> |
| In reply to | #111100 |
On 06/ 2/17 12:55 AM, Malcolm McLean wrote: >> > Apple also sells operating systems pre-installed. It just also manufactures the hardware. > So Microsoft have the more open model. If you want Linux, you have to either build > your own PC from components, or, as we used to do when I was working with Linux, > buy a Windows machine and delete the OS. Or simply do as I did and order my laptop with Ubuntu pre-installed from Dell... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-06-01 23:14 +0200 |
| Message-ID | <20170601231428.9a5735f5613bae5839007211@gmail.com> |
| In reply to | #111143 |
On Fri, 2 Jun 2017 08:32:15 +1200 Ian Collins <ian-news@hotmail.com> wrote: > Or simply do as I did and order my laptop with Ubuntu pre-installed from > Dell... Is it really cheaper than with preinstalled Windows? I would bet Microsoft corrupted computer manufacturers with an anticompetitive practice by prompting them to rise the price of Linux machines if they don't want to pay more for Windows licenses. Did Dell put the price of the Ubuntu license on the bill?
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-06-01 14:41 -0700 |
| Message-ID | <9f227585-ad0c-436d-9670-6c3be2630c3e@googlegroups.com> |
| In reply to | #111148 |
On Thursday, June 1, 2017 at 5:17:46 PM UTC-4, GOTHIER Nathan wrote: > On Fri, 2 Jun 2017 08:32:15 +1200 > Ian Collins <ian-news@hotmail.com> wrote: > > > Or simply do as I did and order my laptop with Ubuntu pre-installed from > > Dell... > > Is it really cheaper than with preinstalled Windows? I would bet Microsoft > corrupted computer manufacturers with an anticompetitive practice by prompting > them to rise the price of Linux machines if they don't want to pay more for > Windows licenses. Did Dell put the price of the Ubuntu license on the bill? The desktop machine I'm currently using at home could have been delivered with any one of three different operating systems, including any desired version of Windows or Linux (I don't remember what the third one was). I selected that vendor precisely because they offered pre-installed Linux. Then I reached the part of the ordering process where I was supposed to specify the operating system to be installed, and missed it (entirely my fault - I just failed to read one important paragraph). As a result, it arrived with the default OS installed, which was Windows. However, it was an unlicensed copy. All I have to do, if I want a licensed copy of Windows, is contact Microsoft and pay their license fee, and I can make full use of that copy (including upgrading it, which I suspect is sorely needed). I've kept that copy in a separate partition, just in case I ever feel a need to do so. That explains why all three options were the same price. Instead, I downloaded Ubuntu Linux and installed it myself, which is precisely the hassle I'd been trying to avoid. But it's a lot less of a hassle than I had with my previous self-installed versions of Linux.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-02 09:48 +1200 |
| Message-ID | <epbgdnFuc47U3@mid.individual.net> |
| In reply to | #111152 |
On 06/ 2/17 09:41 AM, jameskuyper@verizon.net wrote: > On Thursday, June 1, 2017 at 5:17:46 PM UTC-4, GOTHIER Nathan wrote: >> On Fri, 2 Jun 2017 08:32:15 +1200 >> Ian Collins <ian-news@hotmail.com> wrote: >> >>> Or simply do as I did and order my laptop with Ubuntu pre-installed from >>> Dell... >> >> Is it really cheaper than with preinstalled Windows? Yes. > The desktop machine I'm currently using at home could have been delivered with > any one of three different operating systems, including any desired version of > Windows or Linux (I don't remember what the third one was). I selected that > vendor precisely because they offered pre-installed Linux. Then I reached the > part of the ordering process where I was supposed to specify the operating > system to be installed, and missed it (entirely my fault - I just failed to > read one important paragraph). As a result, it arrived with the default OS > installed, which was Windows. However, it was an unlicensed copy. All I have to > do, if I want a licensed copy of Windows, is contact Microsoft and pay their > license fee, and I can make full use of that copy (including upgrading it, > which I suspect is sorely needed). I've kept that copy in a separate partition, > just in case I ever feel a need to do so. That explains why all three options > were the same price. > > Instead, I downloaded Ubuntu Linux and installed it myself, which is precisely > the hassle I'd been trying to avoid. But it's a lot less of a hassle than I had > with my previous self-installed versions of Linux. It's even more hassle with a laptop! Dell provide a tool for generating an install USB, with all of the correct drivers, from the installed laptop so you can install others. Good service all round and a laptop with a quad core Xeon :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-02 00:56 +0200 |
| Message-ID | <ogq5se$j50$1@dont-email.me> |
| In reply to | #111156 |
On 01/06/17 23:48, Ian Collins wrote: > On 06/ 2/17 09:41 AM, jameskuyper@verizon.net wrote: >> On Thursday, June 1, 2017 at 5:17:46 PM UTC-4, GOTHIER Nathan wrote: >>> On Fri, 2 Jun 2017 08:32:15 +1200 >>> Ian Collins <ian-news@hotmail.com> wrote: >>> >>>> Or simply do as I did and order my laptop with Ubuntu pre-installed >>>> from >>>> Dell... >>> >>> Is it really cheaper than with preinstalled Windows? > > Yes. > >> The desktop machine I'm currently using at home could have been >> delivered with >> any one of three different operating systems, including any desired >> version of >> Windows or Linux (I don't remember what the third one was). I selected >> that >> vendor precisely because they offered pre-installed Linux. Then I >> reached the >> part of the ordering process where I was supposed to specify the >> operating >> system to be installed, and missed it (entirely my fault - I just >> failed to >> read one important paragraph). As a result, it arrived with the >> default OS >> installed, which was Windows. However, it was an unlicensed copy. All >> I have to >> do, if I want a licensed copy of Windows, is contact Microsoft and pay >> their >> license fee, and I can make full use of that copy (including upgrading >> it, >> which I suspect is sorely needed). I've kept that copy in a separate >> partition, >> just in case I ever feel a need to do so. That explains why all three >> options >> were the same price. >> >> Instead, I downloaded Ubuntu Linux and installed it myself, which is >> precisely >> the hassle I'd been trying to avoid. But it's a lot less of a hassle >> than I had >> with my previous self-installed versions of Linux. > > It's even more hassle with a laptop! Dell provide a tool for generating > an install USB, with all of the correct drivers, from the installed > laptop so you can install others. Good service all round and a laptop > with a quad core Xeon :) > Do you mean it's more of a hassle installing Windows on a laptop? That is usually true - installing Windows is an almost endless task of trying to get the right drivers. It's especially "fun" when the machine does not have a DVD drive and you have to spend hours creating a boot USB stick, then find that Windows does not support the disk controller or RAID controller, the network interface card, the USB controller, etc. I spent most of a day getting Windows installed properly on a small server recently (the server came without disks or OS). Installation of Linux is usually a half hour job on the same systems, and that's just because I like to be complicated about the disk and filesystem setup. It used to be the case that installation of Linux on laptops could be a challenge, but I rarely see trouble now.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-02 11:12 +1200 |
| Message-ID | <epblbmFuc47U5@mid.individual.net> |
| In reply to | #111167 |
On 06/ 2/17 10:56 AM, David Brown wrote: > On 01/06/17 23:48, Ian Collins wrote: >> >> It's even more hassle with a laptop! Dell provide a tool for generating >> an install USB, with all of the correct drivers, from the installed >> laptop so you can install others. Good service all round and a laptop >> with a quad core Xeon :) >> > > Do you mean it's more of a hassle installing Windows on a laptop? That > is usually true - installing Windows is an almost endless task of trying > to get the right drivers. It's especially "fun" when the machine does > not have a DVD drive and you have to spend hours creating a boot USB > stick, then find that Windows does not support the disk controller or > RAID controller, the network interface card, the USB controller, etc. I > spent most of a day getting Windows installed properly on a small server > recently (the server came without disks or OS). Installation of Linux > is usually a half hour job on the same systems, and that's just because > I like to be complicated about the disk and filesystem setup. > > It used to be the case that installation of Linux on laptops could be a > challenge, but I rarely see trouble now. The stock Ubuntu 16.04.2 USB installer won't boot correctly on a Dell Precision 5520, you need the driver set from Dell. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:54 +0000 |
| Message-ID | <5932a2fb.5770437@news.xs4all.nl> |
| In reply to | #111167 |
David Brown <david.brown@hesbynett.no> wrote: > Do you mean it's more of a hassle installing Windows on a laptop? That > is usually true - installing Windows is an almost endless task of trying > to get the right drivers. Oh, come on, David. You're getting to be as bad as Ballmer in the FUD department. If there's one area in which Linux has historically been provably _worse_ than MS Windows, it's drivers and hardware compatibility. Even to this day, there are printers which are a pain to run under Linux. Really, David, people like you are making the OS movement look as sorry a lot of liars as Microsoft and Apple. Richard
[toc] | [prev] | [next] | [standalone]
| From | Leon Taylor <leontaylor476@gmail.com> |
|---|---|
| Date | 2017-06-03 05:10 -0700 |
| Message-ID | <fa501e9e-6cc7-402f-bbef-90680565d6e4@googlegroups.com> |
| In reply to | #111360 |
>Even to this day, there are printers which are a pain to run under Linux. EpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEpsonEPSON!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-04 14:32 +0200 |
| Message-ID | <oh0ueu$9v4$1@dont-email.me> |
| In reply to | #111360 |
On 03/06/17 13:54, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> Do you mean it's more of a hassle installing Windows on a laptop? That >> is usually true - installing Windows is an almost endless task of trying >> to get the right drivers. > > Oh, come on, David. You're getting to be as bad as Ballmer in the FUD > department. If there's one area in which Linux has historically been > provably _worse_ than MS Windows, it's drivers and hardware > compatibility. Even to this day, there are printers which are a pain to > run under Linux. Oh, I can certainly agree that installing Linux, especially on laptops, /used/ to be a real pain. Getting wireless networking to work could be nearly impossible, and there were endless troubles with modems and printers. I am talking about /now/, and about /my/ experiences. When I am buying new computer hardware (either privately, or at work), I rarely bother to do any research about "Linux compatibility". In most cases, it simply works fine. Usually, Windows systems come with the Windows "pre-installed", and the hardware has all its drivers. "Pre-installed" may mean hours of actual installation of the system plus a wide range of mostly useless trial-ware and ad-ware, followed by hours getting rid of it all (that varies by vendor). But if you have to install Windows from scratch, from a standard Windows installation DVD, you can usually be very sure that it will take a good while to get all the drivers in place. At least these days you are doing it with a vaguely useable screen resolution - I remember when Windows installation was all at 640x480 VGA regardless of your graphics card. There are still plenty of areas where Linux hardware support is not ideal - when getting debuggers or other specialised hardware, you often have to check details of support. (But also, some of that kind of hardware is only supported on particular versions of Windows.) And as you say, there /are/ printers that are a problem in Linux - but they are now rare. And sometimes the very latest graphics cards are a problem in Linux, especially if you are not using a very recent distro or kernel. The last time I installed Windows from scratch on a system, it could not find the disks (no support for the raid card), it could not use most of the USB ports (no support for the USB3 controller), and it could not use the network (no support for either of the two different common network cards). "Almost endless task" is, I admit, an exaggeration - it was about four or five hours effort, and then it took the system about as long again to install all the updates (but all the reboots were automatic). Installing Debian from the net on the same type of system is less than a half hour from start to finish, including all the latest software, and /all/ the hardware is supported out of the box. > > Really, David, people like you are making the OS movement look as sorry > a lot of liars as Microsoft and Apple. > Hey, I don't speak for Linux, its users, its developers, or anything else - this is just my own experience.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-06-01 21:44 +0000 |
| Message-ID | <ogq1s2$fsv$5@news.albasani.net> |
| In reply to | #111148 |
On 2017-06-01, GOTHIER Nathan <nathan.gothier@gmail.com> wrote: > On Fri, 2 Jun 2017 08:32:15 +1200 > Ian Collins <ian-news@hotmail.com> wrote: > >> Or simply do as I did and order my laptop with Ubuntu pre-installed from >> Dell... > > Is it really cheaper than with preinstalled Windows? Here in Serbia 50-100 euros cheaper. That is why laptops that cost 200-300 euros are never sold with Windows here. -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:51 +0000 |
| Message-ID | <5932a286.5653593@news.xs4all.nl> |
| In reply to | #111148 |
GOTHIER Nathan <nathan.gothier@gmail.com> wrote: > Ian Collins <ian-news@hotmail.com> wrote: > > > Or simply do as I did and order my laptop with Ubuntu pre-installed from > > Dell... > > Is it really cheaper than with preinstalled Windows? I would bet Microsoft > corrupted computer manufacturers with an anticompetitive practice by prompting > them to rise the price of Linux machines if they don't want to pay more for > Windows licenses. Did Dell put the price of the Ubuntu license on the bill? You don't need to bet; read the Halloween Documents. Richard
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-06-01 21:38 +0000 |
| Message-ID | <ogq1fr$73b$1@news.xmission.com> |
| In reply to | #111143 |
In article <epbbufFuc47U2@mid.individual.net>,
Ian Collins <ian-news@hotmail.com> wrote:
>On 06/ 2/17 12:55 AM, Malcolm McLean wrote:
>>>
>> Apple also sells operating systems pre-installed. It just also manufactures the
>hardware.
>> So Microsoft have the more open model. If you want Linux, you have to either build
>> your own PC from components, or, as we used to do when I was working with Linux,
>> buy a Windows machine and delete the OS.
>
>Or simply do as I did and order my laptop with Ubuntu pre-installed from
>Dell...
This always ends up costing more than getting a super-cheapy with the
latest WinCrap on it - then doing your own install of Linux.
--
The people who were, are, and always will be, wrong about everything, are still
calling *us* "libtards"...
(John Fugelsang)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-02 11:10 +1200 |
| Message-ID | <epbl6vFuc47U4@mid.individual.net> |
| In reply to | #111150 |
On 06/ 2/17 09:38 AM, Kenny McCormack wrote: > In article <epbbufFuc47U2@mid.individual.net>, > Ian Collins <ian-news@hotmail.com> wrote: >> On 06/ 2/17 12:55 AM, Malcolm McLean wrote: >>>> >>> Apple also sells operating systems pre-installed. It just also manufactures the >> hardware. >>> So Microsoft have the more open model. If you want Linux, you have to either build >>> your own PC from components, or, as we used to do when I was working with Linux, >>> buy a Windows machine and delete the OS. >> >> Or simply do as I did and order my laptop with Ubuntu pre-installed from >> Dell... > > This always ends up costing more than getting a super-cheapy with the > latest WinCrap on it - then doing your own install of Linux. A Precision 5520 isn't a super-cheapy by any stretch of the imagination! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-06-01 23:34 +0000 |
| Message-ID | <ogq89g$ajv$1@news.xmission.com> |
| In reply to | #111169 |
In article <epbl6vFuc47U4@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: >On 06/ 2/17 09:38 AM, Kenny McCormack wrote: >> In article <epbbufFuc47U2@mid.individual.net>, >> Ian Collins <ian-news@hotmail.com> wrote: >>> On 06/ 2/17 12:55 AM, Malcolm McLean wrote: >>>>> >>>> Apple also sells operating systems pre-installed. It just also manufactures the >>> hardware. >>>> So Microsoft have the more open model. If you want Linux, you have to either build >>>> your own PC from components, or, as we used to do when I was working with Linux, >>>> buy a Windows machine and delete the OS. >>> >>> Or simply do as I did and order my laptop with Ubuntu pre-installed from >>> Dell... >> >> This always ends up costing more than getting a super-cheapy with the >> latest WinCrap on it - then doing your own install of Linux. > >A Precision 5520 isn't a super-cheapy by any stretch of the imagination! And that has what to do with anything? -- If it seems like I'm not responding to some moronic criticism that you've posted in response to one of my posts, be aware that I do not debate with idiots. It doesn't mean you've won anything...
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:48 +0000 |
| Message-ID | <5932a18c.5402875@news.xs4all.nl> |
| In reply to | #111051 |
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > GOTHIER Nathan <nathan.gothier@gmail.com> writes: > > > On Wed, 31 May 2017 17:16:24 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> That seems a reasonable choice to me. But I'd wait for others such as > >> Keith to express an opinion. > > > > I prefer undefined behaviours to emphasize the C standard POV since any C > > implementor manage the implementation in its own defined behaviour. In my view > > any specific behaviour wording is a non informative expression for the C > > implementation. > > The problem is that it's very easy for programmers to hit undefined > behavior (and without defined behavior that a warning shall be issued > when undefined behavior is reached). It's very easy if you're sloppy. It's also very easy to avoid if you're even a little bit careful. And if you're _not_ a little bit careful, you shouldn't be programming in the first place. Or driving a car, or chopping onions. > Some other programming languages make it more difficult or more explicit > to attain undefined behavior (eg. using UNSAFE modules, or some other > language construct). How does providing a keyword for undefined behaviour make it any more defined? > The problem is that programmers with decades of experience programming > in C still don't know they're filling their programs with undefined > behavior. Then they don't have decades of experience, they have decades of evading experience. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-01 08:56 -0700 |
| Message-ID | <3b34398c-f5ec-44d8-a7f1-f35037aef24c@googlegroups.com> |
| In reply to | #111003 |
On Wednesday, May 31, 2017 at 10:16:34 AM UTC-5, David Brown wrote: > > And if all general-purpose implementations for a platform have processed a > > certain behavior a certain way, quality general-purpose implementations should > > continue to do likewise unless they document a compelling reason to do > > otherwise. > > No. If all an implementation wants to give you behaviour that you can > rely on, it should document it. Otherwise you are on your own - you > /can/ write code, compile it, and see that it works as you expect, but > you should not expect it to remain working if you change compiler flags, > update to a new version, or make other changes. > > What you are suggesting would be a recipe for stagnation - compilers > could not change and improve because they would have to try to emulate > the unwritten and unspecified behaviour of other tools. Many compilers in the 1990s included switches which would enable certain optimizations, but documented that use of those switches would break certain kinds of programs. Since nothing in the Standard prohibited conforming implementations from providing optional non-conforming modes of operation, such switches could even enable optimizations which would be impossible in any conforming mode. If a programmer explicitly invites a compiler to behave in a fashion contrary to what would otherwise be commonplace behavior, I would regard such explicit invitation as fair basis for treating as "compelling" even the slightest reason for unusual behavior. Further, I would suggest that the ability of switches to invite optimizations beyond those permitted by the Standard would help avoid stagnation. The difference between that and the present state of affairs is that if compilers favor compatibility over performance by default, then feeding an implementation a program that was written for another on a similar platform would be unlikely to yield the fastest possible executable, but would be likely to yield one that would run correctly even if the program used platform-provided features. It would also avoid the need for programmers to avoid using platform-provided features that would be useful on the present implementation for fear that other implementations might break them. > It would also make users' life a lottery - how is the user supposed to > know what the compiler writer sees as a "compelling reason" ? Read the compiler documentation. If e.g. a system has a 32-bit accumulator but defines "int" as 16 bits because a 32-bit store requires using separate store-lower and store-upper operations, that would be a compelling reason for it to process something like "int1+int2 > int3" using 32-bit arithmetic without even offering an option to do otherwise, *provided the implementation documents its deviation from commonplace behavior*. Otherwise, in most cases where an implementation could practically support commonplace behaviors, it should do so *unless switches or directives waive such behaviors*. > > True, but a C implementation whose behavior deviates from those of existing > > general-purpose compilers for similar platforms should not call itself a > > quality general-purpose compiler, since general-purpose compilers should be > > suitable for processing code written for pre-existing general-purpose compilers > > for similar platforms. > > The trick here is very simple - write code that relies on > standards-defined behaviour, and perhaps basic implementation-defined > behaviour (such as the size of an "int") if that is helpful to your code > and you don't need wide portability. Some target architectures have > specified ABIs that compilers will stick to, giving you a nice selection > of implementation-specific behaviour you can rely on across different tools. The Standard does not require implementations to honor guarantees that would seem to be implied by the ABI. If an ABI defines "long long" and "int64_t" as having identical 64-bit representations, for example, and one needs to integrate some code that uses arrays of "long long" with code that uses arrays of "int64_t", writing a function that can operate on both types interchangeably should not be appreciably more difficult than writing a function to process just one or the other, but the Standard doesn't specify any means of doing so (since such a requirement would be meaningless on any implementation where the types might have different representations). I would think the authors of the Standard would have seen obvious benefit to having implementations allow programmers to write such functions in cases where the representations match, but neglected to mandate that implementations do so *precisely because it was so obvious*. Nonetheless, "modern" compiler writers seem to think that it's better to have two alias-incompatible types with the same representation than to e.g. provide a means of declaring an arbitrary number of types with the same representation which are alias- incompatible with each other, but are all alias compatible with int64_t. > If you need something beyond that, your code is tied tightly to the > implementation (possibly even the specific version and flags). That's > fine too - C is designed to allow that kind of coding. Your mistake is > in thinking that /other/ compilers somehow have an obligation to support > /your/ non-portable code. They're free to write whatever they want, but compilers that can run code that uses a wide range of features that other compilers commonly provide will be suitable for more purposes than those which cannot. > But I have never heard of a compiler trying to emulate another > compiler's treatment of undefined behaviour. Can you give real-life > examples? Well, gcc has an option called -fwrapv which exists specifically for that purpose and turns what would otherwise be UB into defined behavior. It also has -fno-strict-aliasing which almost does likewise, except that gcc's documentation, last I checked, failed to actually define the behavior associated with that flag [it says the flag disables certain optimizations, but did not explicitly preclude the possibility that the compiler might decide to generate code that launches "rogue" if it detects pointer aliasing not because it would "optimize" anything, but nothing would forbid it from doing so]. > It is a different thing entirely if the compiler /documents/ the > behaviour, perhaps using a compiler switch. For example, it would be a > bad idea for gcc to emulate old compiler's behaviour of wrapping signed > integer overflows, because it hinders optimisations. But it is a fine > idea to provide a documented "-fwrapv" switch which enables such > wrapping behaviour. /That/ is how you deal with compatibility with old > code that relies on specific undefined behaviour. What advantage is there to that, versus having the compiler default to the old behavior but have command-line switches to loosen the guarantees associated with it? Suppose I have some code which left-shifts negative numbers and I want to ensure that it will work with present and future versions of gcc. Note that the *present* version of gcc documents that it does not exploit the freedom offered by C99, but that wouldn't preclude the possibility of future versions doing so. If future versions could be relied upon not to change the behavior in the absence of an -fneg-lshift flag, present build files' lack of such a flag would be sufficient to ensure correct behavior with those future versions. But if future versions require -fno-neg-lshift flag to achieve present behavior, that would make it impossible to write code and makefile today that would ensure that a future gcc version would continue to process the code in compatible fashion.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-02 14:11 +0200 |
| Message-ID | <ogrkec$dmi$1@dont-email.me> |
| In reply to | #111119 |
On 01/06/17 17:56, supercat@casperkitty.com wrote: > On Wednesday, May 31, 2017 at 10:16:34 AM UTC-5, David Brown wrote: >>> And if all general-purpose implementations for a platform have processed a >>> certain behavior a certain way, quality general-purpose implementations should >>> continue to do likewise unless they document a compelling reason to do >>> otherwise. >> >> No. If all an implementation wants to give you behaviour that you can >> rely on, it should document it. Otherwise you are on your own - you >> /can/ write code, compile it, and see that it works as you expect, but >> you should not expect it to remain working if you change compiler flags, >> update to a new version, or make other changes. >> >> What you are suggesting would be a recipe for stagnation - compilers >> could not change and improve because they would have to try to emulate >> the unwritten and unspecified behaviour of other tools. > > Many compilers in the 1990s included switches which would enable certain > optimizations, but documented that use of those switches would break > certain kinds of programs. That may be true. I don't remember reading such language in compiler documentation, but the 1990's was a long time ago. A compiler is certainly free to add switches that might break programs that are conforming C - for example, I have used compilers that have an option to make "int" 8-bit. And a compiler is also free to document switches that will not break correct C code, but may cause problems for certain common types of incorrect C code. For example, gcc mentions that -fstrict-aliasing assumes code follows the rules applicable to the language being compiled, but notes that it can break some kinds of code that people might write. > Since nothing in the Standard prohibited > conforming implementations from providing optional non-conforming modes of > operation, such switches could even enable optimizations which would be > impossible in any conforming mode. Yes. > > If a programmer explicitly invites a compiler to behave in a fashion > contrary to what would otherwise be commonplace behavior, I would regard > such explicit invitation as fair basis for treating as "compelling" even > the slightest reason for unusual behavior. As is often the case, I can't figure out what you are trying to say. > Further, I would suggest that > the ability of switches to invite optimizations beyond those permitted by > the Standard would help avoid stagnation. > > The difference between that and the present state of affairs is that > if compilers favor compatibility over performance by default, then feeding > an implementation a program that was written for another on a similar > platform would be unlikely to yield the fastest possible executable, but > would be likely to yield one that would run correctly even if the program > used platform-provided features. It would also avoid the need for > programmers to avoid using platform-provided features that would be useful > on the present implementation for fear that other implementations might > break them. As always, the advice is to write code that is correct C code, and to make any implementation-specific behaviour (especially compiler-specific, rather than common platform-specific) as clear and specific as possible. > >> It would also make users' life a lottery - how is the user supposed to >> know what the compiler writer sees as a "compelling reason" ? > > Read the compiler documentation. If e.g. a system has a 32-bit accumulator > but defines "int" as 16 bits because a 32-bit store requires using separate > store-lower and store-upper operations, that would be a compelling reason > for it to process something like "int1+int2 > int3" using 32-bit arithmetic > without even offering an option to do otherwise, *provided the implementation > documents its deviation from commonplace behavior*. Otherwise, in most cases > where an implementation could practically support commonplace behaviors, it > should do so *unless switches or directives waive such behaviors*. There is no such thing as "commonplace behaviours". Behaviour should be documented. If there is some useful behaviour for a particular platform beyond what is written in the C standards, then it should be in the platform documentation. ARM writes ABI documents. PPC has the eABI for embedded systems. x86-64 has the System V ABI for everything expect Windows - and Windows has its own ABI. If you think you can extrapolate some sort of guaranteed behaviour for a target based on what some compilers seem to do on that target (or what they seem to do 25 years ago), then you are wrong. <snip more rambling - TLDR >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-02 10:02 -0700 |
| Message-ID | <3add1ae4-acc5-4ac5-8f92-d62bf9b2d351@googlegroups.com> |
| In reply to | #111211 |
On Friday, June 2, 2017 at 7:11:30 AM UTC-5, David Brown wrote: > On 01/06/17 17:56, supercat wrote: > > Many compilers in the 1990s included switches which would enable certain > > optimizations, but documented that use of those switches would break > > certain kinds of programs. > > That may be true. I don't remember reading such language in compiler > documentation, but the 1990's was a long time ago. A compiler is > certainly free to add switches that might break programs that are > conforming C - for example, I have used compilers that have an option to > make "int" 8-bit. And a compiler is also free to document switches that > will not break correct C code, but may cause problems for certain common > types of incorrect C code. For example, gcc mentions that > -fstrict-aliasing assumes code follows the rules applicable to the > language being compiled, but notes that it can break some kinds of code > that people might write. If a collection of source files does not violate any constraints, and at least one implementation defines its behavior in a fashion meeting its requirements, that collection of files would be a Conforming C Program. The Standard defines a subcategory of Conforming Programs, called Strictly Conforming Programs, whose behavior is fully defined by the Standard, but nothing in the Standard would suggest that non-portable programs which invoke UB are in any way "incorrect", except to people who think that "non-portable or erroneous" is synonymous with "erroneous". > > If a programmer explicitly invites a compiler to behave in a fashion > > contrary to what would otherwise be commonplace behavior, I would regard > > such explicit invitation as fair basis for treating as "compelling" even > > the slightest reason for unusual behavior. > > As is often the case, I can't figure out what you are trying to say. If code includes a directive that invites a compiler to do anything it likes if code performs some action, a compiler shouldn't need much reason to aggressively exploit that. > > Read the compiler documentation. If e.g. a system has a 32-bit accumulator > > but defines "int" as 16 bits because a 32-bit store requires using separate > > store-lower and store-upper operations, that would be a compelling reason > > for it to process something like "int1+int2 > int3" using 32-bit arithmetic > > without even offering an option to do otherwise, *provided the implementation > > documents its deviation from commonplace behavior*. Otherwise, in most cases > > where an implementation could practically support commonplace behaviors, it > > should do so *unless switches or directives waive such behaviors*. > > There is no such thing as "commonplace behaviours". Behaviour should be > documented. If there is some useful behaviour for a particular platform > beyond what is written in the C standards, then it should be in the > platform documentation. ARM writes ABI documents. PPC has the eABI for > embedded systems. x86-64 has the System V ABI for everything expect > Windows - and Windows has its own ABI. If you think you can extrapolate > some sort of guaranteed behaviour for a target based on what some > compilers seem to do on that target (or what they seem to do 25 years > ago), then you are wrong. Most documentation for most things is pretty awful. Compilers are no exception. Would gcc's -fno-strict-aliasing flag have any purpose if it couldn't be relied upon to define the behavior of writing an object as one type and reading as another as being equivalent to converting the first type to a sequence of characters, and then converting the sequence of characters to the second type? Is there anything in the documentation that actually defines that behavior? Last I checked, it merely said that it blocks certain optimizations, but doesn't preclude the possibility that the compiler wouldn't go out of its way to break aliasing in cases where doing so wouldn't improve efficiency (and thus wouldn't be an optimization). If the authors of gcc weren't so insistent that they aren't bound by any behaviors they don't explicitly document that wouldn't be an issue, I would trust that they would regard -fno-strict-alias as defining the meaning of code which makes use of the Common Initial Sequence guarantee, type punning, etc. but given their attitude I see no reason to trust anything less than an explicit statement of precise behavior.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:45 +0000 |
| Message-ID | <5932a11b.5290437@news.xs4all.nl> |
| In reply to | #110991 |
supercat@casperkitty.com wrote: > On Wednesday, May 31, 2017 at 5:51:51 AM UTC-5, David Brown wrote: > > A compiler has /no/ obligation to follow behaviour that is defined > > elsewhere. That includes behaviour that may seem "natural" for the > > target platform, behaviour that other compilers support, behaviour that > > existed in older C versions or standards, or behaviour that is in the > > imagination of the user. > > True, but a C implementation whose behavior deviates from those of existing > general-purpose compilers for similar platforms should not call itself a > quality general-purpose compiler, since general-purpose compilers should be > suitable for processing code written for pre-existing general-purpose compi= > lers for similar platforms. In other words, there should only ever be one compiler for a given platform, and it should behave the way you think it should. Right, got that. Richard
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web