Good day there,
We are presently searching for proficient & knowledgeable people to become part
of our friendly business. We feel that your experience and skills will be an
excellent fit for our team.
Specifications:
- Capability to interact, read, and simply write in English
- Dependable a
Linux https://bit.ly/2JY7Ueo Steven Newbury
I might as well be dead, but I could kill you instead. - PJ Harvey
If you brutalize the world around you, you also brutalize yourself. - Flanders
Falling in Love is a trick our genes pull on our otherwise perceptive mind to
hoodwink us i
On Tue, Dec 08, 2020 at 10:24:08AM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
> Trying to reduce the boot time of standard distributions, I would like to
> get rid of the initrd. The initrd is for mounting the root file system and
> on most end user systems with standard distributions that me
On Tue, 2020-12-08 at 10:24 +0100, Paul Menzel wrote:
Dear Linux folks,
Trying to reduce the boot time of standard distributions, I would like
to get rid of the initrd. The initrd is for mounting the root file
system and on most end user systems with standard distributions that
means loading t
On 08.12.20 11:58, Paul Menzel wrote:
> Thank you. I know this and do it myself. But, the requirement is to use
> the distribution Linux kernel (package). I am sorry for being unclear.
What about rebuilding the distro package ?
Actually, I wonder why using a generic (bloated) full-blown distro
w
Dear Enrico,
Am 08.12.20 um 10:38 schrieb Enrico Weigelt, metux IT consult:
On 08.12.20 10:24, Paul Menzel wrote:
Similar to passing firmware and microcode update files to Linux or
building these into the Linux kernel image, would it be possible to
append the required modules to the Linux ker
On 08.12.20 10:24, Paul Menzel wrote:
> Similar to passing firmware and microcode update files to Linux or
> building these into the Linux kernel image, would it be possible to
> append the required modules to the Linux kernel image, and Linux would
> load these?
Indeed, yes it does. Just set the
Dear Linux folks,
Trying to reduce the boot time of standard distributions, I would like
to get rid of the initrd. The initrd is for mounting the root file
system and on most end user systems with standard distributions that
means loading the bus driver for the drive and the file system drive
On Mon, May 18, 2020 at 1:50 AM Anastassios Nanos
wrote:
>
> On Mon, May 18, 2020 at 10:50 AM Marc Zyngier wrote:
> >
> > On 2020-05-18 07:58, Anastassios Nanos wrote:
> > > To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
> > > QEMU, or some other kind of VM monitor in user
On Mon, 2020-05-18 at 13:51 +0200, Paolo Bonzini wrote:
> On 18/05/20 13:34, Maxim Levitsky wrote:
> > > In high-performance configurations, most of the time virtio devices are
> > > processed in another thread that polls on the virtio rings. In this
> > > setup, the rings are configured to not ca
On 18/05/20 13:34, Maxim Levitsky wrote:
>> In high-performance configurations, most of the time virtio devices are
>> processed in another thread that polls on the virtio rings. In this
>> setup, the rings are configured to not cause a vmexit at all; this has
>> much smaller latency than even a l
On Mon, 2020-05-18 at 13:18 +0200, Paolo Bonzini wrote:
> On 18/05/20 10:45, Anastassios Nanos wrote:
> > Being in the kernel saves us from doing unneccessary mode switches.
> > Of course there are optimizations for handling I/O on QEMU/KVM VMs
> > (virtio/vhost), but essentially what happens is re
On 18/05/20 10:45, Anastassios Nanos wrote:
> Being in the kernel saves us from doing unneccessary mode switches.
> Of course there are optimizations for handling I/O on QEMU/KVM VMs
> (virtio/vhost), but essentially what happens is removing mode-switches (and
> exits) for I/O operations -- is ther
Anastassios Nanos writes:
> On Mon, May 18, 2020 at 11:43 AM Thomas Gleixner wrote:
>>
>> And this shows clearly how simple the user space is which is required to
>> do that. So why on earth would we want to have all of that in the
>> kernel?
>>
> well, the main idea is that all this functionalit
Anastassios Nanos writes:
> Moreover, it doesn't involve *any* mode switch at all while printing
> out the result of the addition of these two registers -- which I
> guess for a simple use-case like this it isn't much.
> But if we were to scale this to a large number of exits (and their
> respec
Anastassios Nanos writes:
> To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
> QEMU, or some other kind of VM monitor in user-space to host the vCPU
> threads, I/O threads and various other book-keeping/management mechanisms.
> This is perfectly fine for a large number of rea
On 2020-05-18 07:58, Anastassios Nanos wrote:
To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
QEMU, or some other kind of VM monitor in user-space to host the vCPU
threads, I/O threads and various other book-keeping/management
mechanisms.
This is perfectly fine for a larg
To spawn KVM-enabled Virtual Machines on Linux systems, one has to use
QEMU, or some other kind of VM monitor in user-space to host the vCPU
threads, I/O threads and various other book-keeping/management mechanisms.
This is perfectly fine for a large number of reasons and use cases: for
instance, r
Hello Sir/Madame
Good day.
I am Rob Turner, Head of Procurement. Our marketing unit
requested your products Models after coming across your Trade
fair catalog last year and Webpage on registered trade site,
we are interested to Purchase your products and its accessories
as requested by our c
Hello Sir/Madame
Good day.
I am Rob Turner, Head of Procurement. Our marketing unit
requested your products Models after coming across your Trade
fair catalog last year and Webpage on registered trade site,
we are interested to Purchase your products and its accessories
as requested by our c
Hi!
> Thank you for your answer.
>
> I've a Raspberry PI 3 and read that this device use it's own fork of the
> Linux Kernel.
> But do you think it would be useful to test linux-next on this device?
Well, if you can get linux-next working there, yes, that would be
nice. But this may be a bit t
Hi Pavel,
Thank you for your answer.
I've a Raspberry PI 3 and read that this device use it's own fork of
the Linux Kernel.
But do you think it would be useful to test linux-next on this device?
Regards
2017-10-23 6:29 GMT-03:00 Pavel Machek :
> Hi!
>>
>> Thank you very much for your time to
Hi!
>
> Thank you very much for your time to answer.
> Will create a VM and install all the enviroment needed to start testing.
> Again, thanks for your suggestions!
Using linux-next on some older (32-bit) machine for daily use would be
very valuable. As most people went 64-bit these days, there
Ken / Kamil,
Thank you very much for your time to answer.
Will create a VM and install all the enviroment needed to start testing.
Again, thanks for your suggestions!
Regards,
Javi
El 26/09/17 a las 06:14, Kamil Konieczny escribió:
On 25.09.2017 21:03, Javier Romero wrote:
Hi,
Last question
On 25.09.2017 21:03, Javier Romero wrote:
> Hi,
>
> Last question, it will be the same to do Kernel testing on a virtual machine,
> or it will be better to do kernel testing over a no virtual machine?
>
> El 24/09/17 a las 17:25, Ken Moffat escribió:
>> On Sun, Sep 24, 2017 at 12:52:08PM -0300,
Hi,
Last question, it will be the same to do Kernel testing on a virtual
machine, or it will be better to do kernel testing over a no virtual
machine?
Regards,
Javi
El 24/09/17 a las 17:25, Ken Moffat escribió:
On Sun, Sep 24, 2017 at 12:52:08PM -0300, Javier Romero wrote:
Hi Ken,
Tha
Hi people,
Well, after reading those links provided by all of you, I'd like to start
contributing as a Kernel tester.
Have also read this link about testing the Kernel:
http://m.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,0
Which are the minimal hardware requirements to
Hi Jon,
Thank you very much for your suggestion.
Best Regards,
Javi
El 22/09/17 a las 16:15, Jonathan Corbet escribió:
On Thu, 21 Sep 2017 18:16:12 -0300
Javier Romero wrote:
My name is Javier, live in Argentina, and work as a Linux Server admin
in the Network Operations Center of an IS
On Thu, 21 Sep 2017 18:16:12 -0300
Javier Romero wrote:
> My name is Javier, live in Argentina, and work as a Linux Server admin
> in the Network Operations Center of an ISP.
>
> Would like to know, how can I start contributing to the Linux kernel.
A good place to start is the documentation on
Hello Kamil,
Thanks for your suggestions.
I'll check those links to learn how can I start contributing.
Best Regards,
Javier Romero
El 22/09/17 a las 07:02, Kamil Konieczny escribió:
On 21.09.2017 23:16, Javier Romero wrote:
My name is Javier, live in Argentina, and work as a Linux Serve
On 21.09.2017 23:16, Javier Romero wrote:
> My name is Javier, live in Argentina, and work as a Linux Server admin in the
> Network Operations Center of an ISP.
>
> Would like to know, how can I start contributing to the Linux kernel.
>
> Sorry for the inconvenience.
see
https://kernelnewbies.
Hello,
My name is Javier, live in Argentina, and work as a Linux Server admin
in the Network Operations Center of an ISP.
Would like to know, how can I start contributing to the Linux kernel.
Sorry for the inconvenience.
Regards,
Javier Romero
On Tue, 31 May 2016 12:07:13 +0300
admin wrote:
> I am the author of a lock-free data structure library, liblfds, which
> has now my first attempt at a port to the Linux kernel, which is to say,
> I have a Kbuild file which produces a static library.
>
> I'm posting as I thought it might be of s
Hi, everyone.
This is my first post to the linux-kernel list.
I am the author of a lock-free data structure library, liblfds, which
has now my first attempt at a port to the Linux kernel, which is to say,
I have a Kbuild file which produces a static library.
I'm posting as I thought it might be
The following changes since commit 45ba5b3e8f91384e652e8c61572bbe06b44a502a:
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux (2016-02-28
13:57:50 -0700)
are available in the git repository at:
https://github.com/jeffmerkey/linux.git tags/mdb-v4.5-rc6
the linux kernel,
> except this time they are not even distributing source (like RedHat does) but
> not the binaries, the source itself is restricted. What do these stable
> patches consist of? It is a diff
> that is created by linux kernel + grsecurity changes to linux kernel +
>
stributing source (like RedHat does) but not the
binaries, the source itself is restricted. What do these stable patches consist
of? It is a diff
that is created by linux kernel + grsecurity changes to linux kernel +
backports of security
patches to the linux kernel. 200 dollars a month if you want i
stributing source (like RedHat does) but not the
binaries, the source itself is restricted. What do these stable patches consist
of? It is a diff
that is created by linux kernel + grsecurity changes to linux kernel +
backports of security
patches to the linux kernel. 200 dollars a month if you want i
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
di
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first four patches make it possible to suppress A.OUT support in the kernel
for an arch (CONFIG_ARCH_SUPPORTS_AOUT must be set to 'y' to unsuppress).
MN10300 does not support the AOUT binfmt, so the ELF binfmt
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch suppresses A.OUT support in the kernel if CONFIG_BINFMT_AOUT=n
and CONFIG_IA32_AOUT=n and CONFIG_BINFMT_AOUT32=n. MN10300 does not support
the AOUT binfmt, so the ELF binfmt should not be permitte
On Thu, Nov 08, 2007 at 02:00:08PM +, David Howells wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > The patch to include/asm-generic/Kbuild.asm doesn't seem to be required.
>
> It is. asm/a.out.h does not exist for MN10300, therefore the export process
> breaks unless it is told not to
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> kbuild does not know anything about ASFLAGS.
> In the whole kernel tree I only see frv assign them but the
> value is never used.
Hmmm... I think it used to be. No matter, I'll drop it from MN10300.
> It just seemed stupid that someone having copyright
Hi David.
> > arch/mn10300/Makefile:
> >
> > 1) Use KBUILD_CFLAGS & KBUILD_AFLAGS & KBUILD_CPPFLAGS - they
> > have replaced the former xFLAGS.
>
> Done. What about ASFLAGS and LDFLAGS?
kbuild does not know anything about ASFLAGS.
In the whole kernel tree I only see frv assign them but the
valu
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> arch/mn10300/Makefile:
>
> 1) Use KBUILD_CFLAGS & KBUILD_AFLAGS & KBUILD_CPPFLAGS - they
> have replaced the former xFLAGS.
Done. What about ASFLAGS and LDFLAGS?
> 2) Consider using unit-y as replacement for UNIT.
> This enable you to do:
> unit-$(C
Hi David.
A few comments to patch #5.
I only looked at the kbuild related stuff - and I have seen
stuff much worse than this.
Yet I have a few comments:
arch/mn10300/Makefile:
1) Use KBUILD_CFLAGS & KBUILD_AFLAGS & KBUILD_CPPFLAGS - they
have replaced the former xFLAGS.
2) Consider using unit-y
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch suppresses A.OUT support in the kernel if CONFIG_BINFMT_AOUT=n
and CONFIG_IA32_AOUT=n and CONFIG_BINFMT_AOUT32=n. MN10300 does not support
the AOUT binfmt, so the ELF binfmt should not be permitte
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The patch to include/asm-generic/Kbuild.asm doesn't seem to be required.
It is. asm/a.out.h does not exist for MN10300, therefore the export process
breaks unless it is told not to export this header. The alternative is to
move this line into each arch's
On Wed, Nov 07, 2007 at 05:43:23PM +, David Howells wrote:
>
>
> These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
> kernel.
>
> The first patch suppresses AOUT support in the kernel if CONFIG_BINFMT_AOUT=n
> and CONFIG_IA32_AOUT=n. MN10300 does not support the AOUT
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch suppresses AOUT support in the kernel if CONFIG_BINFMT_AOUT=n
and CONFIG_IA32_AOUT=n. MN10300 does not support the AOUT binfmt, so the ELF
binfmt should not be permitted to go looking for AOUT lib
Sorry for the late.
On 10/31/07, David Howells <[EMAIL PROTECTED]> wrote:
> > But is there any utility that depends on that uname says mn10300?
>
> autoconf:-)
I forgot again the one as an host environment. :-)
AFAIK, mn10300 series are for embedded systems and I've never heard as
development hos
> Can you guarantee there won't be any non-AM33 variants of mn10300 that need
> supporting? An AM34, perhaps?
>
> So basically, the toolchain name should change from am33 to mn10300 by your
> argument.
Given the "i686" toolchain name is wrong (its actually i686 + cmov) there
is a ton of history
Suzuki Takashi <[EMAIL PROTECTED]> wrote:
> But is there any utility that depends on that uname says mn10300?
autoconf:-)
> I know existing developers should learn the arch name change.
> But how many developers?
I don't know. MEI probably does.
> That's the point. They must always be told or
On 10/31/07, David Howells <[EMAIL PROTECTED]> wrote:
> > But the arch name change does not affect running kernels on consumer
> > devices.
>
> uname says mn10300.
Oh, I forgot.
But is there any utility that depends on that uname says mn10300?
> > Drastic changes in the directory and file struct
> They can if they're told so, plus if they've got the CPU docs to
> hand, it should be more obvious. The AM33 is a variant of the
> MN10300 arch as far as I can tell.
Right, there's also the AM30, AM31, AM32, and AM34. Panasonic calls
the whole series the "AM3" or "MN103 series" although they
Suzuki Takashi <[EMAIL PROTECTED]> wrote:
> But the arch name change does not affect running kernels on consumer devices.
uname says mn10300.
> Drastic changes in the directory and file structures will have
> a much greater impact than that.
Like renaming the arch/mn10300 and include/asm-mn1030
On 10/30/07, David Howells <[EMAIL PROTECTED]> wrote:
> > Why don't you use `am33' for the arch name?
>
> History and the fact that 'mn10300' is what MEI called their arch when they
> originally gave us (RH) their kernel. There are kernels already out there
> running on consumer devices for which
Suzuki Takashi <[EMAIL PROTECTED]> wrote:
> Why don't you use `am33' for the arch name?
History and the fact that 'mn10300' is what MEI called their arch when they
originally gave us (RH) their kernel. There are kernels already out there
running on consumer devices for which it is the mn10300 ar
On 10/29/07, David Howells <[EMAIL PROTECTED]> wrote:
> The second patch adds the architecture itself, to be selected by ARCH=mn10300
> on the make command line.
Why don't you use `am33' for the arch name?
Do you have any plans to support am30 (mn10300) or any pre-am33 processor cores?
I know the
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch makes it possible to suppress AOUT support in the ELF binfmt.
MN10300 does not support the AOUT binfmt, so the ELF binfmt should not be
permitted to go looking for AOUT libraries to load.
The seco
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first patch makes it possible to suppress AOUT support in the ELF binfmt.
MN10300 does not support the AOUT binfmt, so the ELF binfmt should not be
permitted to go looking for AOUT libraries to load.
The seco
Dear friends,
I am a linux user (distro Ubuntu 6.10) with a 2.6.17.10-generic
kernel running on my Acer TravelMate 4672LMi.
I found a line "Please report the result to linux-kernel to fix this
permanently" in my /var/log/kern.log but have no idea where the problem
is because I am
3 of IDE controller :00:1f.1
> PCI: Transparent bridge - :00:1e.0
> PCI: Bus #03 (-#06) is hidden behind transparent bridge #02 (-#02) (try
> 'pci=assign-busses')
> Please report the result to linux-kernel to fix this permanently
> ACPI: PCI Interrupt Routing Table [
transparent bridge #02 (-#02) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *6)
ACPI: PCI Interrupt
> On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> > There is simply no way you can argue that McDonald's failed to
> > warn people
> > about the risks. The cup says "hot" on it,
> Actually, the "HOT" on the cup and the sticker in the drive-through that
> says "Warning: Coffee is served
On Tue, 2007-01-02 at 16:23 -0300, Horst H. von Brand wrote:
> Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> [...]
> > I don't know about others but I wouldn't write an offer with a fixed
> > price for "look into assembler dumps, reverse engineer it and find an
> > infringement on a list of given
On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> There is simply no way you can argue that McDonald's failed to warn people
> about the risks. The cup says "hot" on it,
Actually, the "HOT" on the cup and the sticker in the drive-through that
says "Warning: Coffee is served very hot" were a
On Tue, 02 Jan 2007 12:14:54 PST, David Schwartz said:
>
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
100F == 37C
125F == 52C
55C =
> On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > > The recommendet _serving_ temperature for coffe is 55 °C or below.
> >
> > Nonsense! 55C (100F) is ludicrously low for coffee.
> >
> > 70C (125F) is the *minimum* recommended serving temperature.
> 165-190F is the
> > preferred se
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
> preferred serving range. I can
> How many of them stuffed the cup between their legs though? I think it
> she would have sqeezed the cup too hard and burned her hand and sued
> McDonalds for that people would be more understainding...
How would what she did have any bearing on the key issue, which is whether
or not McDonald's
On Wed, 3 Jan 2007 08:11:21 +1100 Neil Brown wrote:
> Of course if people would just put milk in their coffee, we would have
> this problem :-)
>
> [We now return you to our regular program of filesystem corruption
> and flame wars].
Yes, PLEEZE!
---
~Randy
-
To unsubscribe from this list: send
On Tuesday January 2, [EMAIL PROTECTED] wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > On Tue, 2 Jan 2007, Theodore Tso wrote:
> >
> > > I can very easily believe it. The US patent system and "justice"
> > > system in the US is completely and totally insane, and co
On Tue, Jan 02, 2007 at 06:13:46PM +0100, Jan Engelhardt wrote:
>
> On Jan 2 2007 16:15, David Weinehall wrote:
> >On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> >> On Tue, 2 Jan 2007, Theodore Tso wrote:
> >>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
> > > 2) there had, for a decade prior, been some *700* cases where people
> > > had burned themselves with mcdonald's coffee, so it's not as if
> > > mcdonald's was unaware of th
> The recommendet _serving_ temperature for coffe is 55 °C or below.
Nonsense! 55C (100F) is ludicrously low for coffee.
70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
preferred serving range. I can cite source after source for this. For
example:
http://www.bunn.com
On Tue, Jan 02, 2007 at 07:44:24PM +0100, Bodo Eggert wrote:
> David Weinehall <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit), a
On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
> > > 2) there had, for a decade prior, been some *700* cases where people
> > > had burned themselves with mcdonald's coffee, so it's not as if
> > > mcdonald's was unaware of the danger, yet continued to ignore it.
>
> Given the popul
On Tue, 2 Jan 2007, David Weinehall wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > 1) mcdonald's was not merely serving their coffee "hot," but
> > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > will produce third-degree burns almost immediate
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
[...]
> I don't know about others but I wouldn't write an offer with a fixed
> price for "look into assembler dumps, reverse engineer it and find an
> infringement on a list of given patents" so the patent holder has to
> list the patents and the amoun
On Tue, 2007-01-02 at 08:22 -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
>
> > I can very easily believe it. The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly. Remember t
David Weinehall <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> will produce third-degree burns almost immediately
On Jan 2 2007 16:15, David Weinehall wrote:
>On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> On Tue, 2 Jan 2007, Theodore Tso wrote:
>>
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> wil
> > > > I can very easily believe it. The US patent system and "justice"
> > > > system in the US is completely and totally insane, and companies
> > > > often feel they have to act accordingly. Remember this is the
> > > > country that has issued multi-million dollar awards to people who
> > >
On Tue, Jan 02 2007, David Weinehall wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > On Tue, 2 Jan 2007, Theodore Tso wrote:
> >
> > > I can very easily believe it. The US patent system and "justice"
> > > system in the US is completely and totally insane, and compa
On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
>
> > I can very easily believe it. The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly. Rem
On Tue, 2 Jan 2007, Theodore Tso wrote:
> I can very easily believe it. The US patent system and "justice"
> system in the US is completely and totally insane, and companies
> often feel they have to act accordingly. Remember this is the
> country that has issued multi-million dollar awards to p
On Tue, Jan 02, 2007 at 09:26:14PM +1000, Trent Waddington wrote:
> The list of features which the driver supports is going to be
> sufficient evidence for 99% of patents that relate to computer
> graphics hardware.
Nope, not necessarily. Recall that Patent Office has issued a patent
on the conce
On Tue, 2007-01-02 at 21:26 +1000, Trent Waddington wrote:
> On 1/2/07, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > While this is true (at last in theory), there is one difference in
> > practice: It is *much* easier to prove a/the patent violation if you
> > have (original?) source code than
On 1/2/07, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
While this is true (at last in theory), there is one difference in
practice: It is *much* easier to prove a/the patent violation if you
have (original?) source code than to reverse engineer the assembler dump
of the compiled code and prove t
> I think you're repeating a myth that has become a common part of
> hacker lore in recent years. It's caused by how little we know about
> software patents. The myth is that if you release source code which
> violates someone's patent that is somehow worse than if you release
> binaries that vio
On Tue, 2007-01-02 at 16:30 +1000, Trent Waddington wrote:
[...]
> I think you're repeating a myth that has become a common part of
> hacker lore in recent years. It's caused by how little we know about
> software patents. The myth is that if you release source code which
> violates someone's pat
On 1/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The binary blob in question is several megabytes in size. Now, even
totally *ignoring* who knowingly licensed/stole/whatever IP from who,
that *still* leaves the problem of trying to write several megabytes of
code that doesn't infringe on
1 - 100 of 125 matches
Mail list logo
