60% of the hashrate can easily agree to force a softfork which reduces
the block size. As soon as the fork occurs, there is a very strong
incentive for all the remaining 40% to go along with it: if they
don't, they're mining worthless blocks.
They can use a BIP-34 style mechanism to trigger the f
Or put another way, lowering the block size limit (or cancelling an
increase) is a soft fork. Like all soft forks, a majority of the hash
power can force the soft fork to take place.
On Wed, Jun 24, 2015 at 10:05:42AM -0700, Mark Friedenbach wrote:
> They do so by not building on larger blocks
>
> Consensus is that this process is too painful to go through once a year. I
> agree.
>
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the C
> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% su
As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.
https://gist.github.com/gavinandresen/2355445
I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe t
On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote:
> > What do other people think? Would starting at a max of 8 or 4 get
> > consensus? Scaling up a little less than Nielsen's Law of Internet
> > Bandwidth predicts for the next 20 years? (I think predictability
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
TL;DR: Personally I'm in favour of doing something relatively
unco
otes to stay on
the blockchain whose hashrate has just dropped two orders of magnitude
- so low that the mean time between blocks is now over 16 hours.
>
> And the march 2013 fork showed that miners upgrade at a different schedule
> than the rest of the network.
> On May 7, 2015 5:44 PM
> On the other hand, if 99.99% of the miners updated and only 75% of
> merchants and 75% of users updated, then that would be a serioud split of
> the network.
But is that a plausible scenario? Certainly *if* the concensus rules
required a 99% supermajority of miners for the hard fork to go ahea
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fo
> In this case there is no need for P2P communication, just pay to an
> address you already have for the other party. If you want to avoid
> address reuse, use stealth addressing.
>
> But yes, if you don't have a stealth address for the other party you can
> certainly communicate in private as pee
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty
Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range than
> Why is this? Well, in most jurisdictions financial laws a custodial
> relationship is defined as having the ability, but not the right, to
> dispose of an asset.
So if I leave my window open while I'm out and there's some cash on my
desk, visible from the street, then every passer by now has a
c
Why would we want to have anything to do with people who are hosting
malware? Or do I misunderstand?
On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote:
> There was recently some discussion around dnsseeds. Currently some
> dnsseeds are getting blocked by ISPs because the hosts they pic
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn wrote:
> > Wallets would then be able to persist this data to disk and compete on cool
> > visualisations for how much money you saved over time.
>
> heh, this is a cool idea.
>
> It also
> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first
> one
As a counter argument, many sources (including the BBC) abbreviate
million to 'm' (and billion to 'bn'), e.g. $3m, $3bn.
I think any similarity with SI units here is coincidental.
roy
--
> *Extended validation certs*
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
>1. Unless your domain name *is* your business name like blockchain.info,
>it looks better and gives more in
On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote:
> On Wed, Apr 16, 2014 at 5:12 PM, Kevin wrote:
> > I think we should get to the bottom of this. Should we assume that xp is
> > not secure enough?
>
> Yes.
Do we need a similar warning for OS X 10.6? The EOL of that one is
*far* l
On Mon, Mar 31, 2014 at 01:07:46PM -0400, Jeff Garzik wrote:
> namecoin + SIN[1] or namecoin + PGP identity.
Is namecoin actively maintained these days?
roy
--
___
Bitcoin-de
On Sat, Mar 29, 2014 at 01:42:01PM -0400, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 5:28 pm, Roy Badami wrote:
> > Right now there are also people simply taking base58-encoded private
> > keys and running them through -split.
> >
> > It has a lot going
Right now there are also people simply taking base58-encoded private
keys and running them through -split.
It has a lot going for it, since it can easily be reassembled on any
Linux machine without special software (B Poettering's Linux command
line implementation[1] seems to be included
On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
> On 03/28/2014 07:19 PM, Mike Hearn wrote:
>
> >> Ok, why don't fix this in the spec for now, by defining a fixed expiry
> >> time. In the EU, most products are covered by a 2 years warranty, so it
> >> seems appropriate to pick
On Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote:
> >
> > It's not unusual, in a face-to-face transaction at a bricks-and-mortar
> > establishment, that you know neither the legal name of the entity
> > running the establishment
>
>
> I'd hope that people can get certs for their actual
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
> Yes, this overlaps somewhat with the PKI signing in BIP70, but not
> entirely - you might want to serve unsigned payment requests, but
> still have confidentiality and authenticity for a local face to face
> transaction. The signing and
On Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote:
> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.
At the moment, I imagine the vast majority of
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote:
> On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> >> With the way it works in bitcoinj, the tx is only committed to the wallet
> >> if
> >> the server accepts the Payment message and ACKs i
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> wrote:
>
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
On Wed, Jan 15, 2014 at 11:17:33PM +, I wrote:
> How about just calling them 'type S addresses'?
(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)
with bank routing numbers improves the situation, or
> not...
>
>
> On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami wrote:
> > On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> >> "static address" seems like a reasonable attempt at describing i
On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
...as opposed to an address configured by DHCP?
More seriously, I don't think a typical user will understand anything from
the phrase "static add
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
>
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>
> It's not public. When I say "please pay me" I also say "use this
> multiplier".
Sending a "please pay me" message is really great for business
transactions.
But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:
> With stealth ad
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>ht
rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol. Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this w
> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
>
> That certainly sounds like a plausible use case. You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin
On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen
> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces an
> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.
That does require
On Mon, Dec 09, 2013 at 02:55:02PM +, Drak wrote:
> On 9 December 2013 13:52, Roy Badami wrote:
> >
> > On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote:
> > > Someone needs to update the bitcoin.org website, it still points
> > downloads
> > >
On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote:
> Someone needs to update the bitcoin.org website, it still points downloads
> to 0.8.5
Perhaps because 0.8.6 hasn't been released yet? Or did I miss the
announcement? I think it makes sense that release candidates are not
promoted on bitcoi
> The bitcoin.org domain is controlled by me, Sirius, and an anonymous
> person. Control will not be lost if Sirius becomes unavailable.
I know this will be a controversial viewpoint in some quarters, but
I'm not a fan of anonymity, or of pseudonyms. As far as I know
(please correct me if I'm wro
> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more s
bitrary scripts, messages are handled
> inline, amounts are defined inline. And if you want to rely on the
> payment infrastructure to work, you cannot risk people using the
> old-style static address in the URI.
>
>
>
> On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami wrote:
>
Very brief comment on BIP 72:
I wonder if there should be some discussion included in the
specification as to how the BIP 21 amount, message and label
parameters should be processed when the payment protocol is used.
Presumably amount should be completely ignored? But is the total
amount request
On Thu, Aug 08, 2013 at 07:10:05AM +1000, Gavin Andresen wrote:
> RE: should the customer's machine not broadcast the transaction:
If we're going to allow payments to fail without being broadcast (but
where the wallet can't in general prove that the receiver hasn't seen
the transaction) then I wou
On Wed, Jul 31, 2013 at 05:30:46PM -0600, E willbefull wrote:
> I think it's important to expect PaymentRequest-only bitcoin URIs in the
> future. Some types of payments (exotic transactions) may not make sense to
> have a single fallback address. Or, a page with a bitcoin URI link may be
> relying
On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote:
> I've turned the preliminary payment protocol spec into three BIPs:
>
> https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages
> https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages
> https://en.bitcoin.it/wik
> Sure they are paying themselves, but given bitcoin network
> difficulty is uso high, simply obtaining payments-go-myself-as-miner
> transactions is itself difficult.
Not for pool operators it isn't. Nor for people buying hashing power
from a GPUMAX-type service, if such services still exist (or
by social engineering,
not by breaking the cyrpto.
roy
On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote:
> The attack Schneier is talking about is a collision attack (i.e. it
> creates two messages with the same hash, but you don't get to choose
> either of the messages). It
The attack Schneier is talking about is a collision attack (i.e. it
creates two messages with the same hash, but you don't get to choose
either of the messages). It's not a second preimage attack, which is
what you would need to be able to create a message that hashes to the
same value of an exist
On Mon, Mar 25, 2013 at 02:10:53PM -0700, Gregory Maxwell wrote:
> On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami wrote:
> > I'm not envisaging something as drastic as changing the rules to make
> > transactions to revoked addresses invalid - just an overlay protocol.
> >
On Fri, Feb 22, 2013 at 11:08:51PM +, I wrote:
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet
On Wed, Mar 13, 2013 at 02:27:01PM -0700, Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami wrote:
> > The idea of the client detecting/warning about not-trivial forking
> > seems worthwhile too, though, assuming it doesn't already (AIUI it
> > doesn&#
On Wed, Mar 13, 2013 at 09:14:03PM +, Luke-Jr wrote:
> On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> > On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > > Here's a simple proposal to start discussion from...
> >
> > It seems to me that the biggest failure was not the develop
On Wed, Mar 13, 2013 at 07:28:06PM +0100, Pieter Wuille wrote:
> IMHO, the way to go is first get a 0.8.1 out that mimics the old
> behaviour - just as a stopgap solution.
Presumably not emulate too precisely, at least if your initial report
that the block caused 0.7 to 'get stuck' was correct.
> clients are anyway keeping, and re-relaying, their own transactions
> and hence it would mean only little, and only little for clients.
Not all end-user clients are always-on though
--
Symantec Endpoint Protection 12 po
> Would be nice to have a secure page at bitcoin.org, though, rathar
> than having to go to github - certs from somewhere like Namecheap
> should cost you next to nothing.
And Namecheap now accept Bitcoin :-)
(Complete coincidence - I didn't know that when I posted)
roy
> (The reason for this is that (many? most? all?) CAs verify authority
> by having you place a file at some HTTP path on the domain in
> question.
IME most CAs verify by emailing hostmaster/webaster@ or one of the
contacts in the WHOIS. But you're right, still subject to a MitM.
Still better than
On Sat, Mar 02, 2013 at 04:09:38PM -0500, Gavin Andresen wrote:
> My gpg key is on the bitcoin.org homepage:
> http://bitcoin.org/gavinandresen.asc
> which you can access securely (and see the history of) at:
> https://github.com/bitcoin/bitcoin.org/blob/master/gavinandresen.asc
Would be n
Has anyone been thinking about providing tools to allow users to cope
with key compromise - or more generally, to manage key retirement etc?
atm, if you suspect that your keys may be liable to compromise then
what would you have to do? You'd have to create a new wallet (on a
new computer? or is
On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote:
> You shouldn't need to escape and unescape data that is not being
> interpreted in any way.
Funilly enough pretty much all low-level links that make up the
Internet use either bit-stuffing or byte-stuffing to escape a
particular bit seq
On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote:
> Witness the absurd design of SMTP that means you can't
> start a paragraph with the word From because that's a new-message
> marker!
Actually that has absolutely nothing to do with SMTP. It's down to
the file format of the standard BSD
On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote:
> > I'd still like to understand the rationale for having the merchant
> > broadcast the transaction
>
> There are several reasons for this:
[snip]
All good reasons, thanks for the explanation.
Though I still like my idea of a Validate
I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.
How about this as an alternative proposal:
The buyer's client prepares the transaction and computes its txid. It
then sends a ValidatePurchase message
> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in
Unfortunately I no longer have a working R100 so I can't test.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/104745
Title:
acpi power state changes result in corrupted display [Toshiba Portege
R10
5:06 PM Heikki Vatiainen wrote:
> > On 08/23/2012 08:40 PM, Roy Badami wrote:
> > > Our supplier has confirmed that Digipass authentication (time-based) is
> > > the default mode.
> >
> > Ok, sounds like it has not changed lately.
> >
> > > However
On 10/08/2012 13:26, Heikki Vatiainen wrote:
> On 08/09/2012 06:19 PM, Roy Badami wrote:
>
>> Do you have any experience of ordering GO-6 tokens? Am I right in
>> thinking that Digipass authentication is still Vasco's 'normal'
>> authentication mode - i.e. t
Also potentially a (very minor) code bug in AuthSQLTOTP.pm
checkTOTP() doesn't correctly handle the case where $last_timestep is
undefined (due to a NULL in the database) if the PIN check fails. The
code does contains the line:
$last_timestep += 0; # In case database has NULL
but this lin
uses HMAC-SHA1.
The SQLHOTP doc contains the same error re AES - I haven't verified the
query in the doc as I've not played with that module.
Regards
roy
--
Roy Badami
Roboreus Ltd
Third Floor
The Place
175 High Holborn
Londo
ens with RADIATOR - and we will revisit OAUTH tokens at a later date.
Regards
roy
--
Roy Badami
Roboreus Ltd
Third Floor
The Place
175 High Holborn
London WC1V 7AA
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
le (such as the Feitian c200, which costs about 10 Euros) as a
possible alternative to Vasco tokens, but as with most hardware tokens
there is no way to set the clock, so the ability for the server to
compensate for clock drift is a requirement.
Regards
roy
--
Roy Badami
Roboreus Ltd
Third Floor
The
right in
thinking that Digipass authentication is still Vasco's 'normal'
authentication mode - i.e. that if I don't ask for anything special in
my order, I can expect just normal time-based Digipass authentication,
that will work just like the old GO-1 tokens did?
Regards
roy
Is there a list anywhere of what Vasco token models are supported?
Specifically, I'd like to confirm that the Vasco Digipass GO-6 is
supported, as this seems to be the version of the single button token
that Vasco are pushing these days.
Regards
Roy Badami
--
Roy Badami
Roboreus Ltd
This could be a complete red herring, but on the off chance that it's
useful info:
I'm seeing this issue on an Ultimate-N 6300 in a two-antenna laptop
(with only antenna terminals 1 and 2 connected). This configuration
works fine under Windows, but causes high packet loss under Linux Mint
12. Co
> DNSSEC and ISAKMP are not related.
Well, that's no longer entirely true... AIUI Microsoft seem to have
decided that in their DNSSEC implementation they will use IPsec (and
hence IKE with GSS-API) to secure communications from the client to
the validating resolver (rather than using GSS-TSIG, wh
> Actually there *is* DNSSEC involved or the query would not have
> failed.
Yes, sorry. I meant to imply that there is no DNSSEC involved beyond
the verification of the covering NSEC that proves the lack of a DLV
record.
> There is a bug in the BIND 9.7.0-P1 fixes that triggers this. The
> fix
> > dig www.bbc.net.uk +cd
>
> How does the last query "work"?
What I meant by that, in case it wasn't clear, was that setting the CD
flag in the query caused it query to succeed, hence strongly
suggesting that the cause of the failure in the original query was
related to DNSSEC
> Well, FWIW I upgraded to 9.7.0-P1 and tried enabling DLV again and
> I've seen no repeat of the DNSSEC name resolution issues so far; it's
> early days yet (only been running DLV for three days) but certainly
> looking promissing.
I spoke too soon. I've now found a query that (at least this eve
On Sun, Mar 28, 2010 at 11:48:37PM +0100, I wrote:
> A couple of weeks ago I upgraded my BINDs to 9.7.0 and enabled DLV.
>
> This is my first time attemting to validate DNSSEC; however, I've been
> seeing intermittent failures to resolve domains under .org which have
> been frequent enough to forc
> I have seen this happen when bind for some reason (eg mtu issues with
> vpn) cannot query for the DLV key at dlv.isc.org. I have not figured
> out the exact failure mode there. Check the logs to see errors for DNSKEY
> queries for dlv.isc.org to see if this is happening here too. However in
> tha
> > Yes, I agree freebsd.org is insecure, but I still want to be able to
> > resolve it :-)
>
> The point was, you should not be getting DNSSEC-related errors from
> a domain that is not secured.
I disagree. In order for a validating resolver to resolve freebsd.org
(or any other insecure domain
> It looks to me like your example, freebsd.org, is insecure.
Yes, I agree freebsd.org is insecure, but I still want to be able to
resolve it :-)
.org is signed with NSEC3 and (I think, but could be misremembering)
is using opt-out. org is registered in DLV, so BIND still has to do
some work
A couple of weeks ago I upgraded my BINDs to 9.7.0 and enabled DLV.
This is my first time attemting to validate DNSSEC; however, I've been
seeing intermittent failures to resolve domains under .org which have
been frequent enough to force me to disable DLV again (hence
effectively disabling DNSSEC
> All keys were available to BIND, and the zone was successfully
> resigned just by running dnssec-signzone over the zone with no
> arguments (except for the zone file name).
Hmm, sorry to have posted prematurely - it looks like all keys were
*not* available to BIND due to file ownership issues, b
I have a zone which is DNSSEC signed and is configured as a dynamic
zone (although in practice dynamic updates are not normally used on
this zone). AIUI BIND 9.7.0 should automatically resign the zone as
required as long as the keys are available to it.
However, what I actuallly found is that alt
> Although things seem to be working, I'd like to get to the bottom of
> this so that I can be confident that the machine won't freeze again in
> the future - and I have more serial applications I need to run on this
> server.
I spoke too soon. Although things seemed to be working, SMS Server Too
Can't find anyone else having the same problem as me, so I'm hoping
this is the right place to post...
The short version:
I have a FreeBSD 7.1-RELEASE-p2 machine with a SIIG CyberSerial 4S
card (one of the ones with the 10x clock) and I can fairly
consistently make the machine hang by accessing
FWIW, the Sprint routing issues we were seeing seem to have been
resolved now, AFAICS.
-roy
I'm seeing issues with traceroutes dying at Sprint in London, too.
>From our site here in the UK (transit from NTL Telewest Business) I
can't reach cisco.com (but I know cisco.com is up - I can reach it
from elsewhere). Apparently customers of XS4ALL in the Netherlands
are seeing similar behavio
AFAICS you should *never* call $LAPTOP_MODE start (or stop). You should
always use $LAPTOP_MODE auto (which will then honour the config file
preferences).
-roy
--
power.sh should allow laptop_mode to do it's thing
https://bugs.launchpad.net/bugs/74394
You received this bug notification because
Public bug reported:
If you create a new user in the User and Groups tool, and specify
'admin' as the username, this ends up deleting the existing admin group
when it creates the new user's group. The most visible effects of this
is are that sudo stops working, and that it is no longer possible t
Sorry, I'd forgotten about this bug report, and somehow missed your
query about it.
FTR, a friend of mine helped me track down the issue, which was that the
keyboard layout had somehow been incorrectly configured, presumably when
upgrading at some point.
Specificically XbkLayout was set to "uk" i
Public bug reported:
On a Toshiba Portege R100, running Feisty Beta and trident drivers,
virtual console switching doesn't work once X is running.
The key sequences Ctrl-Alt-F1 etc simply have no effect. Note this is
not a dupe of 68683, as my problem is not that I'm getting corrupted
consoles,
Public bug reported:
On my Toshiba Portege R100 laptop, with trident driver, any attempt to
change the display brightness results in an incorrect resolution. The
screen image is displayed too large by a factor of approximately 2, with
only the top left quadrant of the desktop being visible. This
Public bug reported:
Binary package hint: acpi-support
In 6.06.1 LTS, /usr/acpi/power.sh explicitly calls
laptop_mode start
and
laptop_mode stop
This means that the preferences specified in /etc/laptop-mode/laptop-
mode.conf are not honoured.
Instead, power.sh should simply call
My box that gets IPv6 connectivity from Kewlio (set up via the SixXS
tunnel broker) has a fairly short route which doesn't seem to go via
Japan
traceroute6 to time20.stupi.se (2001:440:1880:1000::20) from 2001:4bd0:202a::1,
64 hops max, 12 byte packets
1 gw-121.lon-01.gb.sixxs.net 3.484 ms 3
Roland> You could also try asking the Isle of Man (.im) Guernsey
Roland> (.gg) and Jersey (.je) how they managed to get a ccTLD
Roland> without being an ISO country.
They got their domains under the old rules, by being a region that the
Universal Postal Union had allocated a region c
william(at)elan> Could you elaborate on how firewall will
william(at)elan> determine if the connection is from mail server
william(at)elan> or from telnet on port 25?
Perhaps because most telnet clients will attempt telnet option
negotiation? If so one could avoid this by using a cl
Google News is your friend
Major power outage hits Los Angeles
http://today.reuters.com/investing/financeArticle.aspx?type=bondsNews&storyID=URI:urn:newsml:reuters.com:20050912:MTFH66743_2005-09-12_20-24-41_N12366749:1
1 - 100 of 212 matches
Mail list logo
